Communication system and method

ABSTRACT

There is provided a system, including a network that is defined by its novel approach to privacy, security and freedom for its users, namely privacy by allowing access anonymously, security by encrypting and obfuscating resources and freedom by allowing users to anonymously and irrefutably be seen as genuine individuals on the network and to communicate with other users with total security and to securely access resources that are both their own and those that are shared by others with them. Functional mechanisms that the system are able to restore open communications and worry-free access in a manner that is very difficult to infect with viruses or cripple through denial of service attacks and spam messaging; moreover, it will provide a foundation where vendor lock-in need not be an issue.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. non-provisional patentapplication Ser. No. 14/260,432, filed Apr. 24, 2014, pending, which isa continuation-in-part of U.S. non-provisional patent application Ser.No. 13/362,384, filed Jan. 31, 2012, patented, which is a continuationof U.S. non-provisional patent application Ser. No. 12/476,229, filedJun. 1, 2009, abandoned, which is a 371 of International ApplicationPCT/GB2007/004421 with an International Filing Date of Nov. 21, 2007,and claiming priority to Great Britain patent application GB0624053.5,filed in Dec. 1, 2006 and Great Britain patent application GB0709759.5,filed May 22, 2007, all of which are relied upon and incorporated hereinby reference.

TECHNICAL FIELD

The present disclosure relates to communication systems, for example tocommunication systems in which data is encrypted and obfuscated byemploying a method of self-encryption. Moreover, the present disclosurealso concerns methods of communicating data within aforesaidcommunication systems, for example to methods of self-encrypting datafor communication and/or storage within aforesaid communication systems.Furthermore, the present disclosure also relates to software productsstored on non-transitory (non-transient) machine-readable data storagemedia, wherein the software products are executable upon computinghardware for implementing aforesaid methods.

BACKGROUND

Contemporary networks are characterized by a combination of vendor lockin, imposed vendor-based controls and a lack of standards; there is thusa need for an improved system and method which allow users to takecharge of a new global communication network in a manner that willmaintain effectiveness and promote the setting and attaining of commongoals. Moreover, issues arise with contemporary communication networksregarding the security and privacy of data; there is thus a need for animproved system and method which allow for a secure private and freecommunication network to be provided, wherein users are able to enjoy anefficiently managed working environment that presents a guaranteed levelof private and securely-protected activity. Such benefits are especiallydesirable when governmental surveillance services are known to eavesdropto a major extent on users' data and data communications, for example inthe contemporary Internet.

Moreover, many contemporary computer resources are underutilised to agreat degree; for example, there is underutilization of disk space, datamemory, data processing power and associated attached resources; suchunderutilization represents inefficiency and is also environmentallydetrimental. There is thus a need for an improved system and method forimproving utilization of these resources and for sharing them globallyto people who purchase them or to people or organisations who are deemedappropriate to benefit from them, such as children in poorer countries,science laboratories, and so forth. Moreover, it is desirable thatallocation from such resource pools, together with other resources, aredecided by system users.

Digital data is often stored on hard disks of individual personalcomputers (PC's) which invariably have data memory and operationaloverhead restrictions. Storage of data on distributed systems such asthe Internet is also possible, but requires specific data storageservers to be available. In addition to such physical systems, datamanagement elements such as security, repair, encryption,authentication, anonymity and mapping and so forth are required toensure successful data transactions and management of data via theInternet. Contemporary systems for messaging and voting exist, but theydo not allow for either authentication on what was voted for, or on lineanonymity. There have been some attempts as listed below, but none ofthese attempts operate in a manner of embodiments of the presentdisclosure.

Known self-healing techniques are divided broadly into two classes. Oneclass pertains to a centralized control system that provides overallre-routing control from a central location of a network; in thisapproach, a re-routing algorithm is employed and establishing of alarmcollection times becomes increasingly complex, as the number of failedchannels increases in the network, and a substantial amount of time willbe taken to collect alarm signals from the network and to transferre-routing information should a large number of channels of amultiplexed transmission system fail. The other class pertains to adistributed approach in which re-routing functions are provided bydistributed points of a given network.

Some attempts have been made to attain some limited aspects ofself-encryption.

A range of limited methods for self-encryption have been developed.

No known systems and methods utilise self-encryption as per embodimentsof the present disclosure, and are related to voice and datatransmissions, or include hardware controllers or servers.

In contemporary systems, secure transactions are achieved throughencryption technologies such as Secure Sockets Layer (SSL), DigitalCertificates, and Public Key Encryption technologies. These systemsaddress attacks by hackers through use of technologies such as Firewallsand Intrusion Detection systems. Associated merchant certificationprograms are designed to ensure a given merchant has adequate inbuiltsecurity to assure reasonably that their consumer transactions will besecure. These systems also ensure that a given vendor will not incur acharge back by attempting to verify the consumer through secondaryvalidation systems such as password protection and, eventually, SmartCard technology.

Network firewalls are typically based on packet filtering which islimited in principle, since rules that judge which packets to accept orreject are based on subjective decisions. Even VPNs (Virtual PrivateNetworks) and other forms of data encryption, including digitalsignatures, are not really safe, because the information can be stolenbefore an encryption process is applied, as default programs are allowedto do whatever they like to other programs or to their data files or tocritical files of an associated operating system.

There are currently several types of centralised file storage systemsthat are used in business environments. One such system is aserver-tethered storage system that communicates with end users over alocal area network (LAN). The end users send requests for storing andretrieving files over the LAN to a file server, which responds bycontrolling storage and/or retrieval operations to provide or store therequested files. While such a system works well for smaller networks,there is a potential bottleneck at an interface between the LAN and thefile storage system.

Another type of centralised storage system is a storage area network,which is a shared, dedicated high-speed network for connecting storageresources to the servers. While the storage area networks are generallymore flexible and scalable in terms of providing end user connectivityto different server-storage environments, the systems are also morecomplex. The systems require hardware, such as gateways, routers,switches, and are thus costly in terms of hardware and associatedsoftware acquisition. Yet another type of storage system is a networkattached storage system in which one or more special-purpose servershandle file storage over the LAN.

Another known file storage system utilizes distributed storage resourcesresident on various nodes, or computers, operating on the system, ratherthan employing a dedicated centralised storage system. These aredistributed systems, wherein clients communicate in a peer-to-peermanner to determine which storage resources to allocate to particularfiles, directories and so forth. These systems are organized as globalfile stores that are physically distributed over the computers on thesystem. A global file store is a monolithic file system that is indexedover the system as, for example, a hierarchical directory. The nodes inthe systems use Byzantine agreements to manage file replications, whichare used to promote file availability and/or reliability. The Byzantineagreements require rather lengthy exchanges of messages and thus areinefficient and even impractical for use in a system in which manymodifications to files are anticipated.

Common e-mail communications of sensitive information is in plain textand is subject to being read by unauthorized code on a given sender'ssystem, during transit and by unauthorized code on a correspondingreceiver's system. Where there is a high degree of confidentiallyrequired, a combination of hardware and software is beneficial forsecuring data. A high degree of security to a computer, or severalcomputers, connected to the Internet or a LAN.

With regard to cash transfers, a truly anonymous purchase is one inwhich a given purchaser and a given seller are unknown to each other,wherein the purchase process is not witnessed by any other person orparty, and the exchange medium is cash. Such transactions are not thenorm. Even cash transactions in a place of business are typicallywitnessed by salespersons and other customers or bystanders, if notrecorded on videotape as a routine security measure. Conversely, commontransaction media such as payment by personal check or credit cardrepresent a clear loss of anonymity, since the purchaser's identity aswell as other personal information is attached to the transaction, forexample driver's license number, address, telephone number, and anyinformation attached to the name, credit card, or driver's licensenumber. Thus, although a cash transaction is not a truly anonymouspurchase, it provides a considerably higher degree of purchase anonymitythan a transaction involving a personal check or credit card, andaffords perhaps a highest degree of purchase anonymity which iscontemporarily achievable. The use of cash, however, has limitations,especially in a context of electronic commerce.

SUMMARY

An object of the present disclosure is to provide an improved system forprotecting data, which is more impervious to eavesdropping and morerobust with regard to data storage.

A further object of the present disclosure is to provide an improvedmethod of operating a system for protecting data, which is moreimpervious to eavesdropping and more robust with regard to data storage.

According to first aspect of the present disclosure, there is provided asystem as claimed in appended claim 1: there is provided a system forprotecting data, wherein the system includes a plurality of users, aplurality of data storage nodes and a data communication network linkingthe plurality of users to the plurality of data storage nodes, whereinthe system is operable to store user data by:

-   (i) dividing the user data into a plurality of data chunks; and-   (ii) applying encryption to the data chunks and/or obfuscating the    data chunks by swapping data between the data chunks, thereby    provided corresponding encrypted and/or obfuscated data chunks; and-   (iii) storing the one or more encrypted and/or obfuscated data    chunks at the plurality of data storage nodes, wherein locations of    the plurality of data storage nodes, whereat the one or more    encrypted and/or obfuscated data chunks are stored, are recorded in    at least one data map.

The system is of advantage in that employing data chunks forrepresenting the user data, wherein the data chunks are encrypted and/orobfuscated, makes it difficult for eavesdropping parties to obtaininformation regarding the user data from analyzing individual encryptedand/or obfuscated data chunks, namely without access to the at least onedata map.

Optionally, in the system, at least one data map is stored in anencrypted form and available in at least one location in the pluralityof data storage nodes.

Optionally, in the system, the data chunks are subject to an encryptionprocess, followed by an obfuscation process, to generate correspondingencrypted and/or obfuscated data chunks, wherein the obfuscation processis implemented using a modulo division function and/or an XOR function.More optionally, in the system, the data chunks are compressed togenerate compressed data chunks which are then subject to theaforementioned encryption process, followed by the aforementionedobfuscation process.

Optionally, in the system, the data communication network is configuredto function as a peer-to-peer (P2P) network.

Optionally, in the system, the data storage nodes at the locationswhereat the one or more encrypted and/or obfuscated data chunks arestored are operable to maintain multiple copies of their respectiveencrypted and/or obfuscated data chunks, and to regenerate fromuncorrupted copies of the encrypted and/or obfuscated data chunks one ormore replacement encrypted and/or obfuscated data chunks to replace anycopy of the encrypted and/or obfuscated data chunks which have beencorrupted.

Optionally, the system is operable to enable the plurality of users toaccess their respective user data, by retrieving at least one encrypteddata map against a user ID, to decrypt the at least one data map todetermine the locations whereat one or more encrypted and/or obfuscateddata chunks are stored, to fetch the one or more encrypted and/orobfuscated data chunks from the locations, to decrypt and/orde-obfuscate the one or more encrypted and/or obfuscated data chunks togenerate one or more corresponding decoded data chunks, and to assemblethe one or more decoded data chunks to regenerate the user data.

Optionally, in the system, the user data corresponds to a currency value(cyber) which is authenticated by an authenticating arrangement of thesystem serving the users. More optionally, the system is operable totransfer ownership of the currency value from one given user to another,by way of registering a change of value ownership at the authenticatingarrangement of the system. More optionally, the system is operable toenable the value to be traded to and/or from corresponding fiatcurrency, physical items and/or services.

Optionally, in the system, known information from the user data is usedby the system as an encryption key for encrypting the data chunks and/orfor encrypting the data map.

Optionally, the system is operable to encrypt each data chunkseparately, and wherein, for each data chunk, known information fromanother chunk is data used as the encryption key.

Optionally, the system is operable to determine a hash value for theuser data, and to use the determined hash value to determine at leastone of: sizes of the data chunks, the number of data chunkscorresponding to the user data.

Optionally, in the system, a symmetric encryption algorithm is employedto encrypt the data chunks and/or the at least one data map. Suchsymmetric encryption is beneficially used to obfuscate and producepseudo-random data, for example for storage at data storage nodes.Moreover, such encryption additionally, or alternatively, renders itdifficult for any eavesdropping parties to guess uncompressible output.

Optionally, the system is operable to swap data between the data chunks,wherein a byte of a first given chunk is swapped with a byte of a secondchunk.

Optionally, the system is operable to determine a hash value of eachdata chunk and to rename the chunk using the determined hash value ofthe data chunk.

Optionally, the system is operable to store the encrypted and/orobfuscated data chunks on a distributed nodal network.

Optionally, the system is operable to determine if each encrypted and/orobfuscated data chunk already exists on the data communication networkand, if each chunk of the data already exists, not storing the encryptedand/or obfuscated data chunk.

Optionally, the system is implemented as a voting system.

Optionally, in the system, the encrypted and/or obfuscated data chunksare generated by a first user and stored at the storage nodes, and theencrypted and/or obfuscated data chunks are decrypted and/orde-obfuscated by the second user, wherein the first and second users aremutually cooperating parties of a secure data, video and/or audiocommunication link.

Optionally, the system is operable to employ deterministic encryptionthat encrypts parts of files individually by chunking the data intodeterminable fixed-size data in a sliding window of several data chunks,wherein the deterministic encryption requires no input except the dataof the files itself, and wherein the system provides in operationdecryption that requires only the at least one data map produced (FIG.2) for executing decryption of the encrypted data chunks.

Optionally, the system is operable to employ encryption keys whenencrypting the data chunks and/or the data map, wherein the encryptionkeys are never reused.

Optionally, in the system, encryption keys that are used are at least aslong as one or more messages in the user data to be encrypted.

Optionally, the system is operable to employ a finger printing algorithmto create pseudorandom data for use when encrypting the data chunksand/or the at least one data map. More optionally, in the system, thefinger printing algorithm is implemented by hashing to generate thepseudorandom data.

Optionally, the system is operable to increase its security of theencrypted and/or obfuscated data chunks proportionately to a chosenhashing algorithm employed by the system. More optionally, in thesystem, the chosen hashing algorithm is a substantially perfect hashingalgorithm, wherein the substantially perfect hashing algorithmapproximates to a one time pad. However, it will be appreciated that aperfect one time pad may potentially not be technically feasible. Ingeneral, a “one time pad”, as defined by Shannon, is defined byconditions:

-   (i) such pads cannot be reused;-   (ii) such pads must be as long (for example, as expressed in bits or    bytes) as a corresponding message to be encrypted; and-   (iii) such pads must contain only random data.    Aforesaid conditions (i) to (iii) are very difficult, or potentially    impossible, to achieve in practice, but an approximation thereto is    feasible using contemporary computing resources.

Optionally, in the system, fingerprinting information from a given datachuck is harvested to transform mathematically other data chucks for thepurpose of encrypting and/or obfuscating the other data chunks togenerate corresponding encrypted and/or obfuscated data chunks forstorage at the storage nodes.

Optionally, the system is additionally operable to filter the user datato generate corresponding metadata, and to make the correspondingmetadata available for data mining processes associated with thirdparties. More optionally, the system is operable to filter the user datausing a filter whose data filtering characteristics are controllable viaone or more user-adjustable parameters.

According to a second aspect of the present disclosure, there isprovided a method as claimed in appended claim 30: there is provided amethod of protecting data, wherein the system includes a plurality ofusers, a plurality of data storage nodes and a data communicationnetwork linking the plurality of users to the plurality of data storagenodes, wherein the method includes storing user data by:

-   (i) dividing the user data into a plurality of data chunks; and-   (ii) applying encryption to the data chunks and/or obfuscating the    data chunks by swapping data between the data chunks, thereby    provided corresponding encrypted and/or obfuscated data chunks; and-   (iii) storing the one or more encrypted and/or obfuscated data    chunks at the plurality of data storage nodes, wherein locations of    the plurality of data storage nodes, whereat the one or more    encrypted and/or obfuscated data chunks are stored, are recorded in    at least one data map.

Optionally, the method includes storing at least one data map inencrypted form in at least one location on one or more data storagenodes.

Optionally, the method includes subjecting the data chunks to anencryption process, followed by an obfuscation process, to generatecorresponding encrypted and/or obfuscated data chunks, wherein theobfuscation process is implemented using a modulo division functionand/or an XOR function. More optionally, in the method, the data chunksare compressed to generate compressed data chunks which are then subjectto the aforementioned encryption process, followed by the aforementionedobfuscation process; in other words a sequence ofchunk->compress->encrypt->XOR->store is beneficially employed.

Optionally, in the method, the data communication network is configuredto function as a peer-to-peer (P2P) network.

Optionally, in the method, the data storage nodes at the locationswhereat the one or more encrypted and/or obfuscated data chunks arestored are operable to maintain multiple copies of their respectiveencrypted and/or obfuscated data chunks, and to regenerate fromuncorrupted copies of the encrypted and/or obfuscated data chunks one ormore replacement encrypted and/or obfuscated data chunks to replace anycopy of the encrypted and/or obfuscated data chunks which have beencorrupted.

Optionally, the method includes arranging for the system to enable theplurality of users to access their respective user data, by retrievingthe at least one encrypted data map against a user ID, to decrypt the atleast one data map to determine the locations whereat the one or moreencrypted and/or obfuscated data chunks are stored, to fetch the one ormore encrypted and/or obfuscated data chunks from the locations, todecrypt and/or de-obfuscate the one or more encrypted and/or obfuscateddata chunks to generate one or more corresponding decoded data chunks,and to assemble the one or more decoded data chunks to regenerate theuser data.

Optionally, in the method, the user data corresponds to a currency value(cyber) which is authenticated by an authenticating arrangement of thesystem serving the users.

Optionally, the method includes arranging for the system to transferownership of the currency value from one given user to another, by wayof registering a change of value ownership at the authenticatingarrangement of the system.

Optionally, the method includes arranging for the system to enable thevalue to be traded to and/or from corresponding fiat currency, physicalitems and/or services.

Optionally, in the method, known information from the user data is usedby the system as an encryption key for encrypting the data chunks and/orfor encrypting the data map.

Optionally, the method includes arranging for the system to encrypt eachdata chunk separately, and wherein, for each data chunk, knowninformation from another chunk is data used as the encryption key.

Optionally, the method includes arranging for the system to determine ahash value for the user data, and to use the determined hash value todetermine at least one of: sizes of the data chunks, the number of datachunks corresponding to the user data.

Optionally, in the method, a symmetric encryption algorithm is employedto encrypt the data chunks and/or the at least one data map.

Optionally, the method includes arranging for the system to swap databetween the data chunks, wherein a byte of a first given chunk isswapped with a byte of a second chunk.

Optionally, the method includes arranging for the system to determine ahash value of each data chunk and to rename the chunk using thedetermined hash value of the data chunk.

Optionally, the method includes arranging for the system to store theencrypted and/or obfuscated data chunks on a distributed nodal network.

Optionally, the method includes arranging for the system to determine ifeach encrypted and/or obfuscated data chunk already exists on the datacommunication network and, if each chunk of the data already exists, notstoring the encrypted and/or obfuscated data chunk.

Optionally, the method includes implementing the system as a votingsystem.

Optionally, in the method, the encrypted and/or obfuscated data chunksare generated by a first user and stored at the storage nodes, and theencrypted and/or obfuscated data chunks are decrypted and/orde-obfuscated by the second user, wherein the first and second users aremutually cooperating parties of a secure data, video and/or audiocommunication link.

Optionally, the method includes arranging for the system to employdeterministic encryption that encrypts parts of files individually bychunking the data into determinable fixed-size data in a sliding windowof several data chunks, wherein the deterministic encryption requires noinput except the data of the files itself, and wherein the systemprovides in operation decryption that requires at least one data map tobe produced (FIG. 2) for executing decryption of the encrypted datachunks.

Optionally, the method includes arranging for the system to employencryption keys when encrypting the data chunks and/or the data map,wherein the encryption keys are never reused.

Optionally, in the method, encryption keys that are used are at least aslong as one or more messages in the user data to be encrypted.

Optionally, the method includes arranging for the system to employ afinger printing algorithm to create pseudorandom data for use whenencrypting the data chunks and/or the at least one data map. Moreoptionally, in the method, the finger printing algorithm is implementedby hashing to generate the pseudorandom data.

Optionally, the method includes arranging for the system to increase itssecurity of the encrypted and/or obfuscated data chunks proportionatelyto a chosen hashing algorithm employed by the system. More optionally,in the method, the chosen hashing algorithm is a substantially perfecthashing algorithm, wherein the substantially perfect hashing algorithmapproximates to a one time pad. However, it will be appreciated that aperfect one time pad may potentially not be technically feasible.However, it will be appreciated that a perfect one time pad maypotentially not be technically feasible. In general, a “one time pad”,as defined by Shannon, is defined by conditions:

-   (i) such pads cannot be reused;-   (ii) such pads must be as long (for example, as expressed in bits or    bytes) as a corresponding message to be encrypted; and-   (iii) such pads must contain only random data.    Aforesaid conditions (i) to (iii) are very difficult, or potentially    impossible, to achieve in practice, but an approximation thereto is    feasible using contemporary computing resources.

Optionally, the method includes harvesting fingerprinting informationfrom a given data chuck to transform mathematically other data chucksfor purpose of encrypting and/or obfuscating the other data chunks togenerate corresponding encrypted and/or obfuscated data chunks forstorage at the storage nodes.

Optionally, the method includes arranging for the system to beadditionally operable to filter the user data to generate correspondingmetadata, and to make the corresponding metadata available for datamining processes associated with third parties. More optionally, themethod includes arranging for the system to filter the user data using afilter whose data filtering characteristics are controllable via one ormore user-adjustable parameters.

According to a third aspect of the present disclosure, there is provideda software product recorded on non-transitory (non-transient)machine-readable data storage media, characterized in that the softwareproduct is executable upon computing hardware for executing a methodpursuant to the second aspect of the present disclosure.

It will be appreciated that features of the invention are susceptible tobeing combined in various combinations without departing from the scopeof the invention as defined by the appended claims.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Embodiments of the present disclosure will now be described, by way ofexample only, with reference to the accompanying drawings in which:

FIG. 1a is a system diagram according to an embodiment of thedisclosure;

FIG. 1b is a diagram of perpetual data elements of the system of FIG. 1a;

FIG. 1c is a diagram of self encryption elements of the system of FIG. 1a;

FIG. 1d is a diagram of datamap elements of the system of FIG. 1 a;

FIG. 1e is a diagram of anonymous authentication elements of the systemof FIG. 1 a;

FIG. 1f is a diagram of shared access elements of the system of FIG. 1a;

FIG. 1g is a diagram of messenger elements of the system of FIG. 1 a;

FIG. 1h is a diagram of cyber cash elements of the system of FIG. 1 a;

FIG. 1i is a diagram of voting system elements of the system of FIG. 1a;

FIG. 2 is a flow chart of the self authentication process for the systemof FIG. 1 a;

FIG. 3 is a diagram of peer to peer interaction for the system of FIG. 1a;

FIG. 4 is a flow chart of the authentication process for the system ofFIG. 1 a;

FIG. 5 is a flow chart of the data assurance event for the system ofFIG. 1 a;

FIG. 6 is a flow chart of the chunking event for the system of FIG. 1 a;

FIG. 7 is an example of chunking performed by the system of FIG. 1 a;

FIG. 8 is a flow chart of the self healing event for the system of FIG.1 a;

FIG. 9 is a flow chart of the peer ranking event for the system of FIG.1 a;

FIG. 10 is a flow chart of the duplicate removal event for the system ofFIG. 1 a;

FIG. 11 is a flow chart for storing perpetual data performed by thesystem of FIG. 1 a;

FIG. 12 is a diagram of a chunk checking process performed by the systemof FIG. 1 a;

FIG. 13 is a flow chart of the storage of additional chunks for thesystem of FIG. 1 a;

FIG. 14 is a flow chart of the self healing process for the system ofFIG. 1 a;

FIG. 15 is a flow chart of saving data for the system of FIG. 1 a;

FIG. 16 is a flow chart of deleting data for the system of FIG. 1 a;

FIG. 17 is a flow chart of a self encryption process of the system ofFIG. 1 a;

FIG. 18 is a flow chart of a shared access process of the system of FIG.1 a;

FIG. 19 is a flow chart of a messenger application for the system ofFIG. 1a ; and

FIG. 20 is a flow chart of a voting application for the system of FIG. 1a.

DETAILED DESCRIPTION

Embodiments of the present disclosure will now be described, whereinreference is made to identifications (IDs) as provided in Table 5 whendescribing the embodiments.

TABLE 5 ID references used for describing embodiments ID referenceDetail MID This is a base ID and is mainly used to store and forgetfiles. Each of these operations requires a signed request. Restoringsimply requires a request with an ID attached. PMID This is the proxyMID which is used to manage receipt of instructions to a given node fromany network node such as get/put/forget, and so forth. This proxy MID isa key pair which is stored on the given node; if stolen, the key paircan be regenerated by simply disabling the thief's stolen PMID, althoughthere is not much that can be done with a PMID key pair. CID ChunkIdentifier, which is simply a chunkid.KID message on a datacommunication network, for example Internet or www. TMID This is today'sID, namely a one time ID as opposed to a one time password. Its purposeis to disguise further users and also ensure that their MID stays assecret as possible. MPID This is a public ID. This is the ID to whichusers allocate their own name and actual data if required. This is theID for messaging via a messenger, for sharing, for non-anonymous votingand for any other method that requires that the user is known. MAID Thisis basically a hash of ad actual public key of the MID, wherein this IDis used to identify user-actions such as put/forget/get implemented onthe network. This allows a distributed PKI infrastructure to exist andto be automatically checked. KID Kademlia ID: this can be randomlygenerated or derived from known and preferably anonymous information,such as an anonymous public key hash as with the aforesaid MAID. In thiscase, it is feasible to use Kademlia as an example overlay network,although this can be almost any type of network in practice. MSID ShareID, namely an ID and key pair specifically created for each share toallow users to interact with shares using a unique key which is notrelated to their MID, which should always be anonymous and separate.

Anonymous authentication employed in embodiments of the presentdisclosure relates to a system authentication and, in particular,authentication of users for accessing resources stored on a distributedor peer-to-peer (P2P) file system. Moreover, such anonymousauthentication has an aim to preserve the anonymity of the users and toprovide secure and private storage of data and shared resources forusers on a distributed data communication system. There is thereforeprovided a method of authenticating access to a distributed systemcomprising steps of:

-   (i) receiving a user identifier;-   (ii) retrieving an encrypted validation record identified by the    user identifier;-   (iii) decrypting the encrypted validation record, so as to provide    corresponding decrypted information; and-   (iv) authenticating access to data in the distributed system using    the decrypted information.

Receiving, retrieving and authenticating activities in the steps (i),(ii) and (iv) are optionally performed on a node in the distributedsystem, preferably separate from a node performing the step ofdecrypting in the step (iii). The method further comprises a step of:

-   (v) generating the user identifier using a hash.    Therefore, the user identifier may be considered unique, and    optionally altered if a coincidental collision of identical    generation of user identities occurs, and suitable for identifying    unique validation records. The step of authenticating access may    preferably further comprise a step of digitally signing the user    identifier. This provides authentication that can be validated    against trusted authorities. The method further optionally comprises    a step of using the signed user identifier as a session passport to    authenticate a plurality of accesses to the distributed system. This    allows persistence of the authentication for an extended session.

The step of decrypting preferably comprises decrypting an address in thedistributed system of a first chunk of data and the step ofauthenticating access further comprises a step of determining theexistence of the first chunk at the address, or providing the locationand names of specific data elements in the network in the form of a datamap as previously describe. This efficiently combines tasks ofauthentication and starting to retrieve the data from the system. Themethod optionally further comprises a step of using the content of thefirst chunk to obtain further chunks from the distributed system.Additionally, the decrypted data from the additional chunks optionallycontain a key pair allowing the user at that stage to sign a packet sentto the network for packet-validation purposes, e them additionally isoptionally employed to self-sign their own identification (ID).

Therefore, embodiments of the present disclosure provide an advantagethat there is no need to have a potentially vulnerable record of a filestructure persisting in one place on the distributed system, as theuser's node constructs its database of file locations after logging ontothe system. Moreover, this allows for a higher degree of data securityand/or user anonymity.

In respect of embodiments of the present disclosure, there is provided adistributed system comprising:

-   -   (a) a storage module which is operable, namely adapted, to store        an encrypted validation record;    -   (b) a client node comprising a decryption module which is        operable, namely adapted, to decrypt an encrypted validation        record so as to provide decrypted information; and    -   (c) a verifying node comprising:        -   (i) a receiving module which is operable, namely adapted, to            receive a user identifier;        -   (ii) a retrieving module which is operable, namely adapted,            to retrieve from the storage module an encrypted validation            record identified by the user identifier;        -   (iii) a transmitting module which is operable, namely            adapted, to transmit the encrypted validation record to the            client node; and        -   (iv) an authentication module which is operable, namely            adapted, to authenticate access to data in the distributed            file system using the decrypted information from the client            node.

The client node is further operable, namely adapted, to generate theuser identifier using a hash. The authentication module is furtheradapted to authenticate access by digitally signing the user identifier.The signed user identifier is used as a session passport to authenticatea plurality of accesses by the client node to the distributed system.The decryption module is further operable, namely adapted, to decrypt anaddress in the distributed system of a first chunk of data from thevalidation record and the authentication module is further adapted toauthenticate access by determining the existence of the first chunk atthe address. The client node is further operable, namely, adapted to usethe content of the first chunk to obtain further authentication chunksfrom the distributed system.

There is provided at least one computer program, namely at least onesoftware product, comprising program instructions for causing computinghardware, for example at least one computer, to perform theaforementioned method employed in embodiments of the present disclosure.At least one computer program is embodied on a recording medium orread-only memory, stored in at least one computer memory, and/or carriedon an electrical carrier signal. Optionally, the at least one computerprogram is stored on non-transitory (non-transient) machine-readabledata storage media.

Additionally, there is optionally performed a check on the system toensure that the user is logged into, namely “login”, a valid node,implemented, for example, by executing a software product package. Thischeck on the system optionally includes an ability of the system tocheck validity of running d.net software by running content hashing orpreferably certificate checking of the node and also the software codeitself.

The private communication software is operable to provide a very secureand distributed data communication and storage system, which is incontradistinction to the contemporary Internet which allows foreavesdropping by governmental spying institutions, and which allows foruser-stored data potentially to be rendered non-confidential by datamining activities undertaken by third parties. An example implementationof such a secure and distributed data communication and storage systememploys a plurality of innovative elements; linked elements for theprivate communication system are shown in FIG. 1. In FIG. 1, thecommunication system includes eight elements PTx, as provided in Table6, which includes twenty eight interlinked functional elements Py, asprovided in Table 7.

TABLE 6 Elements of the communication system Element PTx Detail PT1Perpetual Data PT2 Self encryption PT3 Data Maps PT4 AnonymousAuthentication PT5 Shared access to Private files PT6 ms Messenger PT7Cyber Cash PT8 Worldwide Voting System

TABLE 7 Interlinked functional elements of the communication systemFunctional element Py Detail P1 Peer Ranking P2 Self Healing P3 SecurityAvailability P4 Storage and Retrieval P5 Duplicate Removal P6 StoringFiles P7 Chunking P8 Encryption/Decryption P9 Identify Chunks P10Revision Control P11 Identify Data with Very Small File P12 Logon P13Provide Key Pairs P14 Validation P15 Create Map of Maps P16 Share MapP17 Provide Public ID P18 Encrypted Communications P19 Document SigningP20 Contract conversations P21 Counterfeit Prevention P22 Allow Sellingof Machine Resources P23 Interface with Non-Anonymous Systems P24Anonymous Transactions P25 Anonymity P26 Proven Individual P27Validation of Vote Being Used P28

Use of the communication system for distributed controlled voting willnext be described. Such a controlled voting system requiresself-authentication functionality which will not be described in greaterdetail, with reference to FIG. 2. In FIG. 2, a computer program productis denoted by 1, and consists of a user interface and a chuck server,namely a sub-system for processing in an anonymous manner chunks ofdata; the computer program product is optionally continuously running oncomputing hardware, or is executed by way of a user selecting an icon orsimilar on a user-present graphical interface. Moreover, as denoted by2, a user is able to input some data known to them such as a user id,beneficially a random ID, and a personal identity number (PIN) in thisexample case. These pieces of information, namely the user id and thePIN, may be concatenated together and hashed to create a uniqueidentifier; the unique identify is optionally confirmed via a search inone or more databases to avoid coincidental duplication, asaforementioned. In this example case this is called the MID(communication network ID), as provided in aforementioned Table 5.

Furthermore, as denoted by 3, a TMID, namely today's MID, is retrievedfrom the communication network, the TMID is then calculated as will bedescribed next

The TMID is a single use or single day ID that is constantly changed.This allows the communication system to calculate a hash value based onthe user ID pin and another known variable which is calculable. For thisknown variable, it is convenient, for example, to use a day variablewhich is the number of days since a beginning of an epoch, for exampleJan. 1, 1970. This allows for a new ID daily, which assists inmaintaining the anonymity of the user. This TMID will create a temporarykey pair to sign database chunks and accept a challenge response fromone of more holders of these database chunks. After retrieval andgeneration of a new key pair, the database is put again in newlocations-rendering everything that was contained in the TMID chunkuseless. The TMID cannot be signed by anyone, therefore hackers andsimilar cannot ban an unsigned user from retrieving data chunkscorresponding to this; for example in a DOS attack, it is a specialchunk where the data hash does not match the name of the chunk, as thename is a random number calculated by hashing other information, namelyit is a hash of the TMID as described below:

An example sequence of events in the communication system is as follows:

-   (i) take “dave” as user ID and “1267” as the PIN;-   (ii) combine user ID+PIN, namely dave+1267=dave1267, and then hash    this to generate the MID;-   (iii) compute the day variable, for example today is the 13416^(th)    day since the aforesaid epoch=13416;-   (iv) thereafter take the PIN, and, for example, add in the number    where the pin states, namely 613dav41e1267, wherein “6” is at    beginning and is going around the PIN again;-   (v) so this is done by taking 1^(St) PIN 1, so put first day value    at position 1, then next PIN number 2, so that day value 2 is at    position 2, then next PIN number 6 so that day value 3 is at    position 6, then next PIN number 7 so that day value 4 is at    position 7, then next PIN number is 1, so that day value 5 is at    position 1, again, so the TMID is a hash of 613dav41e1267 and the    MID is simply a hash of dave 1267.    It will be appreciated that (i) to (v) is merely an example    algorithm and many other types of algorithms are alternatively or    additional employed to enforce security to a further degree.

As denoted by 4 in FIG. 2, from the TMID chunk, a map of the user'sdatabase, or one or more lists of files maps, is identified. Thedatabase is recovered from a data communication network supportingoperation of the communication system, which includes the data maps forthe user and any keys passwords, and so forth. The database chunks arestored in another location immediately and the old chunks forgotten.This can be done now as the MID key pair is also in the database and cannow be used to manipulate the user's data.

As denoted by 5 in FIG. 2, the communication system computer programproduct or application, can now authenticate itself as acting for thisMID and put, get or forget data chunks belonging to the user, asappropriate.

As denoted by 6 in FIG. 2, a watcher process and Chunk server alwayshave access to the PMID key pair as they are stored on the user'scomputing hardware, namely the user's machine, itself, so the computinghardware can start, receive and authenticate anonymous put/get/forgetcommands. Moreover, as denoted by 7 in FIG. 2, a DHT ID is required fora node in a DHT network; the DHT ID is optionally randomly generated, oralternatively, it is feasible to use the hash of the PMID public key toidentify the node.

As denoted by 8 in FIG. 2, pertaining MAID, the user is successfullylogged into the communication system, he/she is able to check whether ornot his/her authentication validation records exist on the network ofthe system. These validation records may be as follows:

-   (i) 1: This is a data element stored on the network of the system,    and preferably named with the hash of the MID public Key;-   (ii) 2: It contains the MID public key+any PMID public keys    associated with this user;-   (iii) 3: This is digitally signed with the MID private key to    prevent forgery; and-   (iv) 4: Using this mechanism, there is thereby allowed validation of    MID signatures by allowing any users access to this data element and    checking the signature of it against any challenge response from any    node pertaining to be this MID, as only the MID owner has the    private key that signs this MID. Any adversary or unauthorized party    could not create a private key that matches the public key to enable    a valid digital signature, so forgery is made impossible given    contemporarily available computer resources;-   (v) 5: This mechanism also allows a user to add or remove PMIDS, or    chunk servers acting on their behalf like a proxy), at will and    replace PMID's at any time in case of the PMID machine becoming    compromised. Therefore, this can be regarded as being the PMID    authentication element.

There will next be described PMID (Proxy MID):

-   (i) 1: This is a data element stored on the network and preferably    named with the hash of the PMID public key;-   (ii) 2: It contains the PMID public key and the MID ID, namely the    hash of the MID public key, and is signed by the MID private key,    namely is authenticated;-   (iii) 3: This allows a machine to act as a repository for anonymous    chunks and supply resources to the net for a MID;-   (iv) 4: When answering challenge responses, any other machine will    confirm the PMID by seeking and checking the MAID for the PMID, and    by making sure that the PMID is mentioned in the MAID data element,    otherwise the PMID is considered invalid;-   (v) 5: The key pair is stored on the machine itself, and may be    encoded or encrypted against a password that has to be entered upon    start-up, optionally, in the case of a proxy provider who wishes to    further enhance PMID security; and-   (vi) 6: The design allows for recovery from attack and theft of the    PMID key pair as the MAID data element can simply remove the PMID ID    from the MAID rendering it unauthenticated.

In FIG. 3, an illustration is provided, in schematic form, of apeer-to-peer (P2P) network in accordance with an embodiment of thepresent disclosure. In FIG. 4, there is provided an illustration of aflow chart of the authentication, in accordance with a preferredembodiment of the present disclosure.

With reference to FIG. 3, a peer-to-peer network 2 is shown with datanodes 4 to 12 connected by a data communication network 14. The datanodes 4 to 12 may be Personal Computers (PCs) or any other computinghardwire and/or hardwired logic device that can perform the processing,communication and/or storage operations required to operate theembodiments of the present disclosure. There is employed a file systemwhich typically has many more data nodes of all types than shown in FIG.3; moreover, a PC may act as one or many types of data node describedherein. The data nodes 4 and 6 store chunks 16 of files in the datacommunication network 14. A validation record node 8 has a storagemodule 18 for storing encrypted validation records identified by a useridentifier.

A client node 10 has a module 20 for input of, and generation of, useridentifiers. It also has a decryption module 22 for decrypting anencrypted validation record, so as to provide decrypted information, adatabase or data map of chunk locations 24 and storage 26 for retrievedchunks and files assembled from the retrieved chunks.

A verifying node 12 has a receiving module 28 for receiving a useridentifier from the client node 10. A retrieving module 30 is configuredto retrieve from the data node an encrypted validation record identifiedby the user identifier. Alternatively, in the preferred embodiment, thevalidation record node 8 is the same node as the verifying node 12,namely the storage module 18 is part of the verifying node 12 (not asshown in FIG. 3). A transmitting module 32 is operable to send theencrypted validation record to the client node 10. An authenticationmodule 34 authenticates access to chunks of data distributed across thedata nodes 8 to 12 using the decrypted information.

With reference to FIG. 4, a more detailed flow of the operation of anembodiment of the present disclosure is shown laid out on the diagramwith steps being performed at the User's PC, namely client node 10, on aleft side 40, those of the verifying PC, namely the verifying node 12,in a centre 42 and those of the data PC (node) on the right 44.

A login box 46 is presented, that requires the user's name or otherdetail, for example an e-mail address, namely the same one used in theclient node software installation and registration process, or simply aname, for example a nickname, and the user's unique number, preferablythe user's PIN number. If the user is a “main user”, then some detailsmay already be stored on the PC. If the user is a visitor, then thelogin box appears for the visitor to enter appropriate details.

A content hashed number such as SHA (Secure Hash Algorithm), optionallybeneficially 160 bits in length, is created in 48 from these two itemsof data, namely user name and PIN number. This ‘hash’ is now known asthe ‘User ID Key’ (MID), which at this point is classed as “unverified”within the communication system. This is stored on the network of thecommunication system as the MAID and is simply the hash of the publickey containing an unencrypted version of the public key for latervalidation by any other node. This obviates a requirement for avalidation authority The software on the user's PC then combines thisMID with a standard “hello” code element 50, to create a ‘hello.packet’as denoted by 52. This “hello.packet” is then transmitted with a timedvalidity on the Internet, for example in a situation where thecommunication system is implemented via use of the Internet.

The hello.packet will be picked up by the first node (for thisdescription, now referring as being the “verifying node”), thatrecognises, as denoted by 54, the User ID Key element of thehello.packet as matching a stored, encrypted validation record file,denoted by 56, that it has in its storage area. A login attemptmonitoring system optionally ensures a maximum of three responses. Upontoo many attempts, the verifying PC creates a “black list” fortransmission to peers. Optionally, an alert is returned to the user if a‘black list’ entry is found and the user may be asked to proceed orperform a virus check.

The verifying node then returns this encrypted validation record file tothe user via the data communication network, for example the Internet. Auser's pass phrase denoted by 58 is requested by a dialog box 60, whichthen will allow decryption of this validation record file.

When the validation record file is decrypted, as denoted by 62, thefirst data chunk details, including a “decrypted address”, areextracted, as denoted by 64, and the user PC sends back a request, asdenoted by 66, to the verifying node for it to initiate a query for thefirst “file-chunk ID” at the “decrypted address” that it has extractedfrom the decrypted validation record file, or preferably the data map ofthe database chunks to recreate the database and provide access to thekey pair associated with this MID. The verifying node then acts as a‘relay node’ and initiates a “notify only” query for this “file-chunkID” at the “decrypted address”.

Given that some other node, for this embodiment, referred to as beingthe “data node”, has recognised, as denoted by 68, this request and hassent back a valid “notification only” message 70 that a “file-chunk ID”corresponding to the request sent by the verifying node does indeedexist, the verifying node then digitally signs, as denoted by 72, theinitial User ID Key, which is then sent back to the user. On receptionby the user, as denoted by 74, this verified User ID Key is used as theuser's session passport. The user's PC proceeds to construct, as denotedby 76, the database of the file system as backed up by the user onto thenetwork of the communication system. This file system, namely database,describes the location of all chunks that make up the user's filesystem. Preferably, the ID Key contains irrefutable evidence, such as apublic/private key pair, to allow signing onto the network as authorisedusers; preferably, this is a case of self signing his/her own ID-inwhich case the ID Key is decrypted and the user is valid-selfvalidating.

Furthermore, details of the embodiment will now be described in greaterdetail. A “proxy-controlled” handshake routine is employed through anencrypted point-to-point channel, to ensure only authorised access bythe legal owner to the communication system, then to the user's filestorage database, then to the files therein. The handshaking check isinitiated from the PC onto which the user logs, namely the “user PC”, bygenerating the “unverified encrypted hash” known as the “User ID Key”,this preferably being created from the user's information, preferablye-mail address and their PIN number. This “hash” is transmitted as a“hello.packet” on the Internet, to be picked up by any system thatrecognises the User ID as being associated with specific data that itholds. This PC then becomes the “verifying PC” and will initially act asthe User PC's “gateway” into the communication system during theauthentication process. The encrypted item of data held by the verifyingPC will temporarily be used as a “validation record”, it being directlyassociated with the user's identity and holding the specific address ofa number of data chunks belonging to the user and which are locatedelsewhere in the peer-to-peer (P2P) distributed file communicationsystem. This “validation record” is returned to the User PC fordecryption, with the expectation that only the legal user can supply thespecific information that will allow its accurate decryption.Preferably, this data may be a signed response being given back to thevalidating node which is possible as the ID chunk when decrypted,preferably symmetrically, contains the user's public and private keysallowing non refutable signing of data packets. Preferably, aftersuccessful decryption of the TMID packet, as described above, themachine will now have access to the data map of the database andpublic/private key pair allowing unfettered access to the system.

It should be noted that, in this embodiment, preferably no communicationis carried out via any nodes without an encrypted channel such as TLS,namely Transport Layer Security, or SSL, namely Secure Sockets Layer,being firstly being set up. In a communication system in accordance withthe present disclosure, a peer talks to another peer via an encryptedchannel and the other peer, namely proxy, requests the information, forexample for some space to save information on or for the retrieval of afile. An encrypted link is formed between all peers at each end ofcommunications and also through the proxy during the authenticationprocess. This effectively bans snoopers from detecting who is talking towhom and also what is being sent or retrieved. The initial handshake forself authentication is also over an encrypted link. Such security iseffective at preventing, for example, governmental authoritieseavesdropping on the user's data and communications, even whenconsiderable computing resources are employed to implement sucheavesdropping.

Secure connection is provided via certificate passing nodes, in a mannerthat does not require intervention, with each node being validated byanother, where any invalid event or data, for whatever reason, forexample fraud detection, snooping from node or any invalid algorithmsthat catch the node, will invalidate the chain created by the node. Thisis all transparent to the user, who merely experiences a highly secureand reliable data communication data communication and data storageservice provided by the present communication system.

Further modifications and improvements may be added to the communicationsystem and its methods of operation, without departing from the scope ofthe disclosure herein described.

In FIG. 5, there is provided an illustration of a flow chart of a dataassurance event sequence in accordance with first embodiment of thispresent disclosure.

In FIG. 6, there is provided an illustration a flow chart of a filechunking event sequence in accordance with second embodiment of thispresent disclosure.

In FIG. 7, there is provided an illustration of a schematic diagram of afile chunking example, pursuant to the present disclosure.

In FIG. 8, there is provided an illustration of a flow chart of selfhealing event sequence, as employed in embodiments of the presentdisclosure.

In FIG. 9, there is provided an illustration of a flow chart of peerranking event sequence, as employed in embodiments of the presentdisclosure.

In FIG. 10, there is provided an illustration of a flow chart ofduplicate removal event sequence, as employed in embodiments of thepresent disclosure.

With reference to FIG. 5, guaranteed accessibility to user data by dataassurance is demonstrated by the flow chart. The user data is copied toat least three disparate locations at a step, denoted by 10. Thedisparate locations store data with an appendix pointing to the othertwo locations by a step, denoted by 20, and is renamed with a hash ofcontents. Preferably, such an action is managed by another node, namelya super node acting as an intermediary by a step, as denoted by 30.

Each local copy at user's PC is checked for validity by integrity testby a step, denoted by 40, and in addition validity checks by performingone or more integrity tests, are made that the other two copies are alsostill OK by step, denoted by 50.

Any single node failure initiates a replacement copy of equivalent leafnode being made in another disparate location by a step, denoted by 60,and the other remaining copies are updated to reflect this change toreflect the newly added replacement leaf node by a step, denoted by 70.

The steps of storing and retrieving are beneficially carried out viaother network nodes to mask the initiator, namely the super node, as inthe step 30.

The method further comprises a step of renaming all files with a hash oftheir contents; such an approach increases obfuscation of data withinthe communication system, from a perspective of any eavesdropping thirdparties. Therefore, each file can be checked for validity or tamperingby running a content hashing algorithm such as, for example, MD5 or anSHA variant, the result of this being compared with the name of thefile.

With reference to FIG. 6, there is provided a methodology to achievemanageable sized data elements and to enable a complimentary datastructure for compression and encryption, wherein the methodologyemploys a step of file chunking. By user's pre-selection, the nominateddata elements, namely files, are passed to undergo a chunking process.Each data element, namely, is split into smaller chunks by a step,denoted by 80, and the data chunks are encrypted by a step, denoted by90, to provide an enhanced degree of security for the data chunks. Thedata chunks are stored locally at step, denoted by 100, ready forperforming network transfer of copies within the communication system.The person, namely user, or the group, to whom the overall data belongs,may, alternatively may not, know the location of these data chunks, inthe step 100, or the other related but dissimilar chunks of data in thestep 100, or the other related but dissimilar chunks of data. Alloperations are conducted within the user's local system. No data ispresented externally, which represents a fundamentally differentapproach to convention data communication and storage, for example in aknown contemporary “cloud computing” system which is highly susceptibleto eavesdropping and snooping by governmental organisations and thirdparties performing data mining of user data.

Each of the aforementioned data chunks does not contain locationinformation for any other dissimilar data chunks. This provides for,security of data content, a basis for integrity checking and redundancy.

The method further comprises a step of only allowing the person, namelythe user, or group to whom the data belongs, to have access to it,preferably via a shared encryption technique. This allows persistence ofthe data within the madisafe.net system.

The checking of data or chunks of data between machines in thecommunication system is carried out via any presence-type protocol suchas a distributed hash table network.

In an event that all data chunks have been relocated, for example whenthe user has not logged on for a while, a redirection record is createdand stored in a super node network of the communication system, forexample a three copy process-similar to data, therefore when a userrequests a check, the redirection record is given to the user to updatetheir database. This efficiently allows data resilience in cases where anetwork churn of the communication system is a problem, as in peer topeer or distributed networks.

With reference to FIG. 7, there is an illustration of an example of flowchart of a method of file chunking. The User's normal file has, forexample, a 5 Mbyte document, which is chunked into smaller variablesized data chunks, for example 135 kbyte, 512 kbyte, 768 kbyte in anyorder. All data chunks may be compressed and encrypted by using a passphrase. In a next step, the method involves individually hashing datachunks and given hashes as names for the hashed data chunks. Then, adatabase record as a file is made from names of the hashed data chunksbrought together, for example in an empty version of the original file(C1########,t1,t2,t3: C2########,t1,t2,t3, and so forth); this file isthen sent to a transmission queue in a storage space allocated to theclient, namely user, application.

Referring next to FIG. 8, there is provided a self-healing eventsequence methodology. Such self healing is required to guaranteeavailability of accurate data within the communication system. As dataor data chunks become invalid by failing integrity test by a step,denoted by 110, the location of failing data chunks is assessed asunreliable and further data from the leaf node is ignored from thatlocation by a step, denoted by 120. A ‘Good Copy’ from a ‘known good’data chunk is recreated in a new and equivalent leaf node. Data or datachunks are recreated in a new and safer location by a step, denoted by130. The leaf node with failing data chunks is marked as unreliable, andthe data therein as “dirty” by a step, denoted by 140. Peer leaf nodesbecome aware of this unreliable leaf node and add its location to watchlist by a step, denoted by 150. All operations associated with the stepsin FIG. 8 are conducted within the user's local system, for example onhis/her PC. Beneficially, no data is presented externally, therebymaintaining a high degree of security and anonymity, for example tounauthorized surveillance by governmental authorities. Therefore, theintroduction of viruses, worms, spy-bots, and so forth, will beprevented and faulty machines/equipment identified automatically in thecommunication system. Beneficially, the network of the communicationsystem optionally uses SSL- or TLS-type encryption to preventunauthorized access or snooping.

Referring next to FIG. 9, Peer Ranking ID is required to ensureconsistent response and performance for a level of guaranteedinteraction recorded for the user. For Peer Ranking, each node, namelyleaf node, monitors its own peer node's resources and availability in ascalable manner, wherein each leaf node is constantly monitored.

In the communication system, each data store, whether a network service,physical drive and so forth, is monitored for availability.Beneficially, a qualified availability ranking is appended to one ormore leaf storage node addresses by consensus of a monitoring super nodegroup by a step, denoted by 160. A ranking figure will be appended bythe step 160, and signed by the supply of a key from the monitoringsuper node; this is optionally agreed by more super nodes to establish aconsensus for altering the ranking of the node. The new rank willpreferably be appended to the node address, or by a similar mechanism toallow the node to be managed preferably in terms of what is storedthere, and how many copies there has to be of the data for it to be seenas perpetual.

In the communication system, each piece of data is checked via a contenthashing mechanism for ensuring its data integrity, which is carried outby the storage node itself by a step, denoted by 170, or by its partnernodes via super nodes by a step, denoted by 180, or by an instigatingnode via super nodes by a step, denoted by 190, by retrieving andrunning the hashing algorithm against that piece of data. The datachecking cycle optionally repeats itself.

In the communication system, as a peer, whether an instigating node or apartner peer, namely one that has a same data chunk, checks the data,wherein the super node querying the storage peer will respond with theresult of the integrity check and update this status on the storagepeer. The instigating node or partner peer will decide to forget thisdata and will replicate it in a more suitable location. If data failsthe integrity check, the node itself will be marked as ‘dirty’ by astep, denoted by 200, and a “dirty” status appended to the leaf nodeaddress to mark it as requiring further checks regarding the integrityof the data it holds by a step, denoted by 210. Additional checks areoptionally carried out on data stored on the leaf node marked as ‘dirty’by a step, denoted by 220. If a pre-determined percentage of data foundto be “dirty”, the node is removed from the communication systemnetwork, except for message traffic by a step, denoted by 230. In anevent of a certain percentage of dirty data being established byaforesaid steps, the communication system may conclude that this node iscompromised or otherwise damaged and the network would be informed ofthis. At that point, the node will be removed from the network exceptfor the purpose of sending it warning messages by a step, denoted by230. This allows either having data stored on nodes of equivalentavailability and efficiency or dictating the number of copies of datarequired to maintain reliability with the communication system.

Further modifications and improvements may be added without departingfrom the scope of embodiments of the disclosure herein described.

Referring next to FIG. 10, duplicate data is optionally removed in thecommunication system to increase, for example maximize, an efficient useof the disk space available within the system. Prior to the initiationof the data backup process by a step, denoted by 240, internallygenerated content hash may be checked for a match against hashes storedon the Internet by a step, denoted by 250, or a list of previouslybacked up data; this will allow a number of replicate copies of data tobe kept for robustness. Moreover, this reduces a network-widerequirement to backup data, which has mutually similar contents.Notification of shared key existence is beneficially passed back to aninstigating node in a step, denoted by 260, to access that an authoritycheck has been requested, which has to pass for signed result to bepassed back to the storage node. The storage node passes shared key anddatabase back to instigating node by a step, denoted by 270. Such datais beneficially backed up via a shared key, which after proof of thefile existing on the instigating node in the step 260, the shared key,in the step 270, is shared with this instigating node. The location ofthe data is then passed to the node for later retrieval, if required.Moreover, this maintains copyright as parties, for example persons, canonly backup what they prove to have on their systems and not publiclyshare copyright infringed data openly on the network of thecommunication system. Furthermore, this data may be marked as protected,or not protected, by a step, denoted by 280, which has a check carriedout for protected, or non-protected, data content. The protected dataignores sharing process.

Next, perpetual data will be described, in respect of the communicationsystem, with reference of FIG. 1, namely the aforesaid element PT1, andalso with reference to FIG. 11.

According to a related aspect of the present disclosure, pertaining tothe communication system and its manner of operation, a file is chunkedor split into constituent parts, denoted by 1, this process involvescalculating a chunk size, preferably from known data such as the firstfew bytes of a hash of the file itself and preferably using a modulodivision technique, for example based on an exclusive OR operation, toresolve a figure between optimum minimum and optimum maximum chunk sizesfor network transmission and storage.

Preferably, each data chunk is then encrypted and obfuscated in somemanner to protect the data; such obfuscation after applying a hashfunction is beneficially achieved by applying an XOR function, forexample XOR'ing one data chunk against another for obfuscation purposes.Optionally, a search of the network is carried out looking for valuesrelating to the content hash of each of the chunks, as denoted by 2.

When looking for such values of the hash content, If this is found, asdenoted by 4, then the other chunks are identified too; failure toidentify all chunks may mean there is a collision on the network of filenames or some other machine is in the process of backing up the samefile. A back-off time is beneficially calculated to check again for theother chunks. If all chunks are on the network, the file is consideredbacked up and the user will add their MID signature to the file afterpreferably a challenge response to ensure there is a valid user andthere are enough resources to do this.

If no chunks are found on the network of the communication system, theuser preferably via another node, denoted by 3, will request the savingof the first copy, preferably in distinct time zones or by employing oneor more other geographically dispersing methods. Thereafter, the chunkwill be stored, as denoted by 5, on a storage node, allowing visibilityof the PMID of the storing node and storage thereof.

Then, preferably, a Key.value pair of a chunkid.public key of theinitiator is written to the network of the communication system,creating a Chunk ID (CID), as denoted by 6.

There will next be described storage and retrieval of data within thecommunication system, with reference to FIG. 1, for example the elementP4.

According to a related aspect of the present disclosure, data is storedin the madisafe.net system in multiple locations. Each locationbeneficially stores locations of its peers that hold identical chunks,namely at least identical in content, and they all communicate regularlyto ascertain the health of the data which is mutually storedtherebetween. A preferable method includes steps as provided in Table 8;the steps are optionally implemented in various different orders to anorder of steps as depicted in Table 8. Optionally, certain steps areomitted.

TABLE 8 Steps of a preferable method of storing data in mutuallycooperating locations Step Detail S1 Copying the data to at least threedisparate locations S2 Performing each copy via many nodes to mask theinitiator S3 Checking each local copy for validity, and making checksthat the preferably other 2 copies are also still valid S4 In an eventof any single node failure, initiating a replacement copy to be made inanother disparate location and updating the other associated copies toreflect this change S5 Carrying out the steps of storing and retrievingvia other network nodes to mask the initiator S6 Renaming all files witha hash of their contents S7 Altering one or more names of the data,namely as data chunk, by a known process such as a binary shift left ofa section of the data; this allows the same content to exist, but alsoallows the chunks to appear as three different bits of data for the sakeof not colliding on the network

Preferably, each data chunk has a counter associated therewith, namely“attached to it”, that allows the network to determine, namely tounderstand easily, just how many users are attached to the data chunk,either by sharing or otherwise. A user requesting a “chunk forget”command or instruction will initiate a system question if they are theonly user using the data chunk, and, if so, the data chunk will bedeleted and the user's required disk space reduced accordingly. Such afeature allows users to remove files no longer required, and to free uptheir local disk space. Any file also being shared is preferably removedfrom the user's quota and the user's database record or data map, aswill be elucidated in greater later, is deleted.

Preferably, this counter is digitally signed by each node sharing thedata and therefore will require a signed “forget” or “delete” command tocause its removal from the communication system. Preferably, even“store”, “put”, “retrieve” and “get” commands, in respect of a givendata chunk, are also either digitally signed or preferably go through aPKI-challenge response mechanism. This PKI-challenge response mechanismassists to prevent unauthorized third parties from attempting to disruptor damage operation of the communication system by attempting to deleteone or more data chunks.

In order to ensure fairness, execution of the method is beneficiallymonitored by a supernode or similar, namely to ensure that the user hasnot simply copied the data map for later use without giving up the diskspace for it. Therefore, the user's private ID public key isbeneficially used to request the “forget chunk” statement. This is usedto indicate the user's acceptance of the “chunk forget” command andallow the user to recover the disk space. Any requests against the datachunk will preferably be signed with this key, and consequently rejectedunless the user's system gives up the space required to access thisfile.

Preferably, each user storing a data chunk will append their signedrequest to the end of the data chunk in an identifiable manner, forexample prefixed with 80- or similar.

Forgetting the data chunk means that the signature is removed from thefile. This again is done via a signed request from the storage node aswith the original backup request. Preferably, this signed request isanother small data chunk stored at the same location as the data chunkwith an appended postfix to the data chunk identifier to show a privateID is storing this chunk. Any attempt by somebody else to download thefile is rejected unless they first subscribe to it, namely a chunk iscalled 12345, so a file is saved and called 12345<signed store request>.This allows files to be forgotten when all signatories to the data chunkare gone. A user sends a signed “no store” or “forget” and their ID datachunk will be removed, and in addition if they are the last user storingthat data chunk, the data chunk is removed. Preferably, this allows aprivate anonymous message to be sent upon data chunk failure or damage,thereby allowing a proactive approach to maintaining clean data.

Preferably, as a given node of the communication system fails, the othernodes preferably send one or more messages to all sharers of the datachunk to identify the new location of the replacement data chunk.

Preferably, any node attaching to a file which is downloadingimmediately should be considered to give rise to an alert, and thecommunication system optionally beneficially takes steps to slow downthis node's activity, or even halt it to protect against potential datatheft.

Next, checks performed on data chunk will be described with reference toTable 9, in conjunction with FIG. 1 and FIG. 12, namely with regard toaforementioned element P9.

TABLE 9 Checks performed on data chunks within the communication systemChecking step Detail 1. Checking A storage node of the madisafe.netsystem containing a peers given data chunk 1 checks its peers, namelyits peer nodes. As each peer node is checked, it reciprocates the check.These checks are preferably split into two types: (a) An availabilitycheck, namely a simple network ping or similar; and (b) A data integritycheck; in this instance, the checking node takes a chunk and appendsrandom data to it and takes a hash of the result. It then sends therandom data to the node being checked and requests the hash of the chunkwith the random data appended. The result is compared with a knownresult and the chunk will be assessed as either healthy or not. If not,further checks with other nodes occur to find the bad node. In such amanner, the storage node determines peer nodes that are likely to bereliable for the concurrent storage of data chunks. 2. Checking Theremay be multiple storage nodes, depending on the multiple rating ofmachines and other factors pertaining to the storage nodes communicationsystem. The above checking is carried out by all nodes from 1 to n(where n is total number of storage nodes selected for the chunk).Obviously, a poorly rated node will required to give up disk space inrelation to the number of chunks being stored to allow perpetual data toexist within the communication system. This is a penaltypaid by nodesthat are switched off. 3. Integrity of A given user who stored the datachunk will check on a data chunk chunk from one storage node which israndomly selected. This check will ensure the integrity of the datachunk and also ensure there are at least ten other signatures existingalready for the data chunk. If there are not such other signaturesexisting, and the user's ID is not listed, the user signs the datachunk. 4. Checking Another example of another user checking the chunk isof a data shown. Note that the user checks X (40 days in this chunkdiagram) are always at least 75% of the forget time retention (Y)(namely, when a chunk is forgotten by all signatories, it is retainedfor a period of time Y). This is optionally another algorithm that willcontinually develop in the madisafe.net system.

Next, storage of additional data chunks will be described with referenceto FIG. 12 and also Table 10.

TABLE 10 Storage of additional data chunks in the communication systemStorage step Detail 1. Chunk ID The communication system employs aprogram, wherein, with user logged in (so an MID exists), has “chunked afile”, namely caused a file to be sub-divided into data chunks. It hasalready stored a chunk and is now looking to store additional chunks.Therefore a Chunk ID (CID) should exist on the communication network.This process retrieves this CID. 2. CID The CID as shown in storing aninitial data chunk contains the data chunk name and any public keys thatare sharing the data chunk. In this instance, it should only be a givenuser's key, as the given user is the first party storing the datachunks, wherein others would be in a back-off period to see if the givenuser backs up other data chunks. Beneficially, a last bit is optionallyany function on any bit as long as it replicable by the given user. 3.Collision There is then performed a check that there will not be aavoidance collision with any other stored chunk on the net; there issearch performed again a CID search. 4. Broadcast A broadcast is henissues to the given user's supemodes, to namely to the supernodes towhich the given user is supernodes connected, stating that the givenuser needs to store X bytes and any other information about where thegiven user requires to store it, for example geographically in the givenuser's case-time zone (TZ). 5. Supernode The supernode network finds astorage location for the finds a given user with the correct rank, andso forth. storage location 6. Storage The data chunk is stored after asuccessful challenge after response, namely in the communicationnetwork. MIDs are challenge require to ensure they are talking ordealing with validated response nodes, so to accomplish this a challengeprocess is carried out as follows, wherein a sender is denoted by “[S]”,and a receiver is denoted by “[R]”: [S] I wish to communicate(store/retrieve/forget data etc.) and I am MAID; [R] retrieves MAIDpublic key from DHT and encrypts a challenge (possibly a very largenumber encrypted with the public key retrieved); [S] gets key anddecrypts and encrypts [R] answer with his challenge number alsoencrypted with [R]'s public key; [R] receives response and decrypts hischallenge and passes back answer encrypted again with [S] public key(Communication is now authenticated between these two nodes.) 7. UpdateThe CID is then updated with the second chunk name and CID the locationit is stored at. This process is repeated for as many copies of a chunkthat are required. 8. Copies of Copies of chunks will be dependent onmany factors chunks including file popularity (popular files may requireto be more dispersed closer to nodes and have more copies. Very poorlyranked machines may require an increased amount of chunks to ensure theycan be retrieved at any time (poorly ranked machines will therefore haveto give up more space)).

Next, issues of security and availability of data will be described withreference to FIG. 1, namely element P3.

According to a related aspect of the present disclosure of thecommunication system and its method of operation, data of each file issplit into relatively small chunks and thereafter encrypted to providesecurity for the data. Only a person or a group, to whom the overalldata belongs, will know locations of corresponding related, butdissimilar, chunks of data corresponding to the aforesaid file. Asdescribed elsewhere in this disclosure, by encrypting and obfuscatingthe data chunks, a higher degree of data secrecy is maintained, namelysubstantially impervious to unauthorized eavesdropping by governmentalorganisations, such as, for example, NSA (USA) and GCHQ (UnitedKingdom). A high degree of data storage reliability is maintained byspreading risk regarding where the encrypted and obfuscated data chunksare stored, in combination to a plurality of copies of each data chunkbeing stored. Preferably, each of the above data chunks does not containlocation information for any other dissimilar chunks; this provides forsecurity of data content, as well as a basis for performing integritychecking and redundancy of data content.

Preferably, the method employed in the communication system furthercomprises a step of only allowing the person, or the group, to whom thedata belongs to have access to it, preferably via a shared encryptiontechnique which allows persistence of the data.

Preferably, in the method, checking of data or chunks of data, namely,data chunks, between machines of the madisafe.net system is carried outvia any presence-type protocol such as a distributed hash table network.

Preferably, in an event when all data chunks have been relocated, namelythe user has not logged on for a while, a redirection record is createdand stored in the super node network, namely a three copyprocess-similar to data; thus, when a user requests a check, theredirection record is given to the user to update his/her database. Suchan approach provides enhanced operating efficiency, which in turn allowsdata resilience in cases where network churn is a problem, namelyability of the network to handle flows of data, as in peer to peer ordistributed networks. This system message can be preferably passed viathe messenger system described herein.

Preferably, the communication system may simply allow a user to searchfor his/her data chunks and through a challenge response mechanism,locate and authenticate himself/herself to have authority to get/forgetthis data chunk.

Furthermore, users can decide on employing various modes of operation,preferably such as:

-   (i) maintain a local copy of all files on their local machine,    unencrypted or chunked;-   (ii) or chunk and encrypt even local files to secure machine,    preferably referred to as off line mode operation; or indeed-   (iii) users may decide to remove all local data and rely completely    on preferably the communication system or similar system to secure    their data.

Next, there will be described a method of self-healing of data withinthe communication system, with reference to FIG. 1 and the element P2therein. According to a related aspect of the present disclosure, thereis provided a self healing network method via us of a process, asfollows:

-   (i) as data or data chunks become invalid from a given location,    data is ignored from that location;-   (ii) data or data chunks are recreated in a new and safer location;-   (iii) the original location is marked as bad; and-   (iv) peers note this condition and add the bad location to a watch    list.    The network is optionally the data communication network of the    meadsafe.net system. Moreover, steps (i) to (iv) beneficially assist    to prevent the introduction of viruses; worms and similar, and also    allow faulty machines/equipment to be identified automatically.    Preferably, the communication system employs a network layer which    employs SSL or TLS channel encryption to prevent unauthorised access    or snooping.

Next, there will be described self-healing of data or data chunks, withreference to FIG. 13 and also Table 11.

TABLE 11 Method of self-healing Step Detail 1. A data element called aChunk ID (CID) is created for each data chunk. Added to this is the“also stored at <1 >MID” for the other identical data chunks. The otherdata chunk names are also here as they may be renamed slightly, forexample by bit shifting a part of the name in a manner that iscalculable. 2. All storing nodes (related to this data chunk) have acopy of this CID file, or can access it at any stage from the DHTnetwork, giving each node has knowledge of all other nodes. 3. Each ofthe storage nodes has their copy of the data chunk. 4. Each node queriesits partner nodes' availability at frequent intervals. On less frequentintervals, a data chunk “health check” is requested. This involves anode creating some random data and appending this to its data chunk andtaking the hash. The partner node will be requested to take the randomdata and do likewise and return the hash result. This result is checkedagainst the result the initiator had and chunk is then deemed healthy ornot. Further tests can be done as each node knows the hash their chunkshould create and can self check n that manner on error and report adirty node. 5. Now there arises a node fail, namely a dirty chunk beingcreated. 6. The first node to note this carries out a broadcast to othernodes to say it is requesting a move of the data. 7. The other nodesagree to have CID updated; they may optionally carry out their own checkto confirm this. 8. A broadcast is sent to the supernode network closestto the storage node that failed, to state a re-storage requirement. 9.The supernode network picks up a request associated with the broadcast.10. The request is to the supernode network to store x amount of data ata rank of y. 11. A supernode will reply with a location. 12. The storagenode and new location carry out a challenge response request to validateeach other, namely invoke a mutual validation response. 13. The chunk isstored and the CID is updated and signed by the three or more nodesstoring the chunk.

Next, there will described peer ranking with reference to FIG. 1, andits associated element P1.

According to a related aspect of the present disclosure, there isprovided an addition of a peer ranking mechanism, wherein each node,namely “leaf node” of a data communication network, for example asemployed in the communication system, monitors its own peer node'sresources and availability in a scalable manner. Nodes beneficiallyconstantly perform this monitoring function. Such a manner of operationof the nodes assists the communication system to function in adistributed manner.

Each data store of the aforesaid data communication network, whether itis a network service, physical drive, and so forth, is monitored foravailability. A ranking figure is appended and signed by a supplying ofa key from a monitoring super node, wherein the key is preferably agreedby one or more other supernodes to establish a consensus before alteringthe ranking of a given node of the data communication network.Preferably, the new rank will be appended to the node address, or by useof a similar mechanism, to allow the given node to be managed in termsof what is stored therein, and how many copies there has to be of thedata stored for it to be regarded, namely “seen”, as being perpetual.

In the aforementioned peer ranking method, each piece of data is checkedvia a content hashing mechanism. This is preferably carried out by thestorage node itself or by its one or more partner nodes via supernodes,or by employing an instigating node via supernodes by retrieving andrunning the hashing algorithm against that piece of data.

Preferably, as a peer, whether an instigating node or a partner peer,namely one that has same chunk, checks the data, the supernode queryingthe storage peer will respond with the result of the integrity check andupdate this status on the storage peer. The instigating node or partnerpeer will decide to forget this data and will replicate it in a moresuitable location. If the data fails the integrity check, the nodeitself will be marked as “dirty” and this status will preferably beappended to the node's address for further checks on other data to takethis into account. Preferably, by establishing that a certain percentageof data is dirty data, it is concluded therefrom that this node iscompromised or otherwise damaged and the network is beneficiallyinformed of this. At that point, the node will be removed from thenetwork, except optionally for a purpose of sending it warning messages.

In general, the madisafe.net system computes a node ranking figure whichtakes into account at least one of:

-   (i) an availability of a given network connection within the    communication system;-   (ii) an availability of resources within the communication system;-   (iii) a time on the network with a rank, wherein the rank is useful    for performing effort-based trust modelling; and-   (iv) an amount of resource that is available within the    communication system network, and also connectivity capabilities of    any node, namely whether it is directly or indirectly contactable.

Such an approach allows data to be stored on nodes of equivalentavailability and efficiency, and to determine the number of copies ofdata required to maintain reliability of data storage within thecommunication system.

Next, a “put” operation occurring within the communication system willbe described with reference to FIG. 15 and also Table 12. Here, the MIDis the MID of the machine saving data to the net, and the PMID is the IDof the storage node chunk server. The communication is therefore betweena communication application with a logged-in user, namely to provide acorresponding MID, and a chunking system on the net somewhere, forexample in a storage node.

TABLE 12 Steps of a “put” operation within the communication system StepDetail 1. A message is signed with a user's MID, namely checked bygetting the MAID packet from the net, is received for requesting storageof a data chunk. 2. This message is a specific message stating thestorage node's ID (PMID) and the data chunk name to be saved and signed,namely this is a unique message. 3. The chunk server decides if it willstore the data chunk. 4. A signed message is returned stating if PMIDwill store this data chunk (chunkID). 5. The data chunk is stored andchecked, for example using a SHA check. 6. A message is sent back tostate that the data chunk is saved and is OK. This is signed by the PMIDof the data chunk server. 7. The data chunk server awaits the locationsof the other identical chunks. 8. Locations of the identical data chunksreturned to the chunk server are signed with the MID. 9. Each storagenode is contacted and public keys exchanged (PMIDs). 10. The data chunkchecking process is initiated.

Next, a “forget” operation within the communication system will bedescribed with reference to FIG. 16.

TABLE 13 Steps of a “forget” operation within the communication systemStep Detail 1. A user has requested that a file should be deleted fromhis/her backup, namely “forgotten” from the communication system. Thesystem signs a request using the user MID. 2. The request is sent to achunk server, for example a data chunk storage node. 3. The storage nodepicks up the request. 4. The storage node sends the signed request tothe other storage nodes that have this data chunk. 5. The MID is checkedas being on the list of MIDs that are watching the chunk; it will beappreciated that only a few, for example twenty, are ever listed. 6. Theother storage nodes are notified of this. 7. If this is the only MIDlisted, then all owners are possibly gone. 8. Chunk delete timer begins;this timer will always be higher than a user check interval, namely thetimer of 60 days-user check interval 40 days. 9. This information isalso passed to other storage nodes.

Next, a method of removing duplicate data chunks in the communicationsystem will be described, namely “Duplicate Removal”, with reference toFIG. 1, in respect of element P5 thereof.

According to a related aspect of the present disclosure, prior to databeing backed up, a content hash may be checked against a list ofpreviously backed up data. This will allow only one backed-up copy ofdata to be kept, thereby reducing the network wide requirement in thecommunication system to backup data that has mutually similar content,for example mutually exactly same content. Preferably, such afunctionality is achieved via performing a simple search for existenceon the net of all data chunks of a particular file.

Preferably, such data is backed up via a shared key, or mechanism ofappending keys, to chunks of data, namely data chunks. After proof ofthe file existing on a given instigating node, the shared key is sharedwith the instigating node and the storing node issues a challengeresponse to add their ID to a pool, if it is capable of carrying outactions on the file such as get/forget; the “forget” functionalitycorresponds to “delete”. The location of the data is then passed to thenode for later retrieval, if required.

Such deletion of duplicate copies of data in the communication system isbeneficially in respect of enforcement of copyright, namely it maintainscopyright as users, for example persons, can only backup what they proveto have as data on their systems; it is thereby not easy publicly toshare copyright-infringed data openly on the network. Preferably, datamay be marked as protected or not protected; for examplecopyright-sensitive content can be marked as “protected” to reduce arisk of copyright infringement occurring. Preferably protected dataignores sharing processes invoked within the communication system.

Next, chunking of data, namely “chunking”, within the communicationsystem will be described with reference to FIG. 1 and the aforementionedelement P7 thereof.

According to a related aspect of the present disclosure, data files aresplit, namely sub-divided, preferably using an algorithm to work out anappropriate data chunk size when splitting the data files into severalcomponent parts. The size of the parts is preferably worked out fromknown information about a corresponding file, or files, as a whole,preferably the hash of the complete file, or files. This information isrun through an algorithm, such as adding together the first x bits ofthe known information and using a modulo division to give a chunk sizethat allows the file to preferably split into a plurality of parts, forexample at least three parts.

Preferably, known information from each data chunk is used as anencryption key. This is preferably done by taking a hash of each chunkand using this as the input to an encryption algorithm to encryptanother chunk in the file. Preferably, there is used a symmetricalencryption algorithm, such as an AES256 encryption algorithm. As will bedescribed in further detail later, after encryption, data chunks arebeneficially subject to further processing to increase theirobfuscation, for example data chunks are XOR′ed against each other.

Preferably, this key is input into a password creating algorithm such asa pbkdf algorithm, and an initial vector and key calculated from that.Preferably, an iteration count for the pbkdf algorithm is calculatedfrom another piece of known information, preferably a sum of bits ofanother chunk, or similar.

Preferably, each initial chunk hash and the final hash after encryptionare stored somewhere for later decryption, for example included in oneor more data maps which enable stored encrypted data chunks to berecovered by an associated user of the communication system and thenappropriately decoded to enable access to a data file corresponding tothe stored encrypted data chunks; the one or more data maps arebeneficially stored in the communication system in an encrypted state.

Next, a method of self encrypting files will be described with referenceto FIG. 1, in respect of the element PT2 thereof, and also withreference to FIG. 17. Reference is also made to Table 14.

TABLE 14 Steps of a method of self encrypting files Step Detail 1. Takea content hash of a file or data element. 2. Chunk a file withpreferably a random calculable size, namely based on an algorithm of thecontent hash (to allow for recovery of the file). Also, obfuscate thefile such as in step 3 3. Obfuscate the chunks to ensure safety, even ifencryption is eventually broken, as occurs with all encryption if givenenough processing power and time: (a) chunk 1 byte 1 swapped with byte 1of chunk 2 (b) chunk 2 byte 2 swapped with byte 1 chunk 3 (c) chunk 3byte 2 swapped with byte 2 of chunk 1 (d) This (a) to (c) repeats untilall bytes are swapped and then repeats the same number of times as thereare chunks with each iteration making next chunk first one, namelysecond time round chunk 2 is in a starting position 4. Take hash of eachchunk and rename chunk with its hash. 5. Take h2 and first x bytes of h3(6 in an example case here) and either use modulo division or similar toget a random number between two fixed parameters (in the example case1000) to get a variable number. Use the above random number and h2 asthe encryption key to encrypt hi or use h2 and the random number asinputs to another algorithm (pdbfk2 in the example case) to create a keyand iv.(initialisation vector) 6. This process may be repeated multipletimes to dilute any key throughout a series of chunks. 7. Chunk namei.e. hi (unencrypted) and h1c (and likewise for each chunk) is writtento a location for later recovery of the data. Added to this, it ispossible simply to update such a location with new chunks if a file hasbeen altered, thereby creating a revision control system where each filecan be rebuilt to any previous state. 8. The existence of the chunk willbe checked on the net to ensure it is not already backed up. All chunksmay be checked at this time. 9. If a chunk exists, all chunks must bechecked for existence. 10. The chunk is saved. 11. The file is marked asbacked up. 12. If a collision is detected the process is redone alteringthe original size algorithm (2) to create a new chunk set, each systemwill be aware of this technique and will do the exact same process tilla series of chunks do not collide. There will be a back off period hereto ensure the chunks are not completed due to the fact another system isbacking up the same file. The original chunk set will be checkedfrequently in case there are false chunks or ones that have beenforgotten. If the original names become available the file is reworkedusing these parameters.

Next, there will be described a method of duplicate removal implementedin the communication system, with reference to FIG. 1, and in respect ofthe aforementioned element P5.

According to a related aspect of the present disclosure, data which ischunked and ready for storing can be stored on a distributed network,but a search is beneficially carried out for checking for the existenceof all associated chunks created. Preferably, the locations of thechunks have the same ranking, from an earlier ranking system asaforementioned, as user or better, otherwise the existing chunks on thenet are promoted to a location of equivalent rank at least. If allchunks exist, then the file is considered as already having been backedup. If less than all chunks exist, then this will preferably beconsidered to be a collision, after a time period, and the file will bere-chunked using one or more secondary algorithms, namely preferablyjust adjusted file sizes. This allows duplicate files on any two or moremachines only to be backed up once, although through perpetual dataseveral copies will exist of each file; this is limited to an amountthat will maintain perpetual data.

Next, a method of encrypt-decrypt in the communication system will bedescribed with reference to FIG. 1, namely in respect of theaforementioned element P8.

According to a related aspect of the present disclosure, the actualencrypting and decrypting within the communication system is carried outvia knowledge of the file's content and this is somehow maintained, aswill be described in greater detail below. Keys are generated andpreferably stored for decrypting. Actually activities of encrypting thefile will preferably include a compression process and furtherobfuscation methods, for example applying XOR operations to encrypteddata chunks for obtaining further obfuscation. Preferably, the datachunk is stored with a known hash, preferably based on the contents ofthat chunk, as aforementioned.

Decrypting the file preferably requires a collation of all data chunksand thereafter rebuilding of the file itself, namely rebuilding the filegiving that gave rise to the data chunks. The file may preferably haveits content mixed up by an obfuscation technique rendering each chunkuseless on its own.

Preferably, every file is subjected in the communication system to aprocess of byte-swapping, or preferably bit-swapping, between its chunksto ensure the original file is rendered useless without all chunks. Suchbit-swapping or byte-swapping is to be regarded as a form of obfuscationprocess.

This process preferably involves running an algorithm, which preferablytakes the data chunk size, and then distributes the bytes in apseudo-random manner, preferably taking the number of chunks and usingthis as an iteration count for the process. Moreover, this beneficiallyprotects data, even in an event of a third party, namely somebody,getting hold of the encryption keys, as the chunks of data are rendereduseless, even if transmitted “in the open” without encryption havingbeen employed. Such a method is able to circumvent surveillance bygovernmental eavesdropping organisations, for example NSA (USA) and GCHQ(United Kingdom), thereby avoiding potential imposition of a policestate, for example. Moreover, such obfuscation defends against somebodycopying all data and storing for many years until decryption ofcontemporary encryption algorithms is possible; it is not anticipatedthat such decryption will be feasible until many years in the future.

This also defends against somebody; instead of attempting to decrypt achunk by creating the enormous amount of keys possible, for example inan order of 254 keys, rather instead creating the keys and presentingchunks to all keys; if this were possible, which is unlikely, a datachunk would decrypt. The process defined here makes this attemptuseless.

When encryption and obfuscation of data chunks has been applied, alldata is to be considered to be diluted throughout the original datachunks and preferably additions to this algorithm will only strengthento a greater extent the process of obfuscation of data in thecommunication system.

Next, a method of identifying data chunks will be described, withreference to FIG. 1, and in respect of the aforementioned element P9.

According to a related aspect of the present disclosure, a data chunk'soriginal hash, or one or more other calculable unique identifiers, isstored. Such stored data preferably with the final name of the datachunk. This aspect defines that each file has a separate map, preferablya file or database entry, to identify the file and the name of itsconstituent parts. Preferably, this map includes local information tousers, such as its original location and associated rights, such asread-only rights in the system, and so forth. Preferably, some of thisinformation can be considered shareable with others, such as filename,content hash and data chunk names.

Next, there will be described ID data with its associated small file,namely data maps, with reference to FIG. 1, and with reference to theaforementioned element P11.

According to a related aspect of the present disclosure, these data mapsmay be very small in relation to the original data itself, therebyallowing transmission of files across networks such as the Internet withextreme simplicity, security and bandwidth efficiency. Preferably, thetransmission of maps will be carried out in a very secure manner, butfailure to do this is akin to currently emailing a file in its entirety.Moreover, the communication system is thus capable of being hosted viathe contemporary Internet, but is also capable of being hosted in othertypes of data communication networks.

Moreover, ID data allows a very small file, such as the data map ordatabase record, to be shared or maintained by a user in a location notnormally large enough to fit a file system of any great size, such as ona PDA, smart phone, mobile phone and similar. The identification of thedata chunk names, original names and final names are all that isrequired in order to retrieve the data chunks and rebuild the file (fromwhich the data chunks are generated) with certainty.

With data maps in place, as aforementioned, a user's whole machine, orall its data, can exist elsewhere. Simply retrieving the data maps ofall data is all that is required to allow the user to have a completevisibility and access to all his/her data as well as any shared files towhich he/she has agreed.

Next, there will be described a method of revision control in thecommunication system, with reference to FIG. 1, and with reference tothe aforementioned element P10; revision control is required whenupdating data stored in the communication system as data chunks.

According to a related aspect of the present disclosure, as data isupdated and the data map contents are altered to reflect the newcontents, this will preferably not require the deletion or removal ofexisting chunks, but instead allow the existing chunks to remain and themap appended to with an indication of a new revision existing.Preferably, further access to the file will automatically open the lastrevision unless requested to open an earlier revision. Such a manner ofrevision control reduces a volume of data flow occurring within thecommunication system when data files are updated and such updates are tobe recorded securely and reliably in corresponding data chunks.

Preferably, revisions of any file can be forgotten or deleted,preferably after checking the file counter or access list of sharers asabove. This allows users to recover space from revisions that are nolonger required.

Next, there is described a method of creating a map of data maps, withreference to FIG. 1, with reference to the aforementioned element P15.

According to a related aspect of the present disclosure, dataidentifiers, preferably data maps as aforementioned, are appended toeach other in a way that preferably allows a single file or databaserecord to identity several files in one, namely as a form of share. Sucha share can be private to a given individual, thereby replacing adirectory structure of files that users are normally acquainted, andreplacing this with a new structure of shares which is very similar tovolumes or filing cabinets, as this is more in line with normal humannature and should make things simpler when using the communicationsystem.

Next, there will described shared maps within the communication system,with reference FIG. 1, and with respect to the aforementioned elementP16.

According to a related aspect of the present disclosure, this map,namely shared map, of maps will preferably identify the users that areconnected to the shared map via some public ID that is known to eachother user, with the shared map itself being passed to users who agreeto join such a share. Moreover, the sharing is preferably implementedvia an encrypted channel, such as an ms messenger or similar. Thisshared map may then be accessed at whatever rank level users have beenassigned. Preferably, there will be associated access rights such asread/delete/add/edit as is typically used in a contemporary context. Asa map is altered, the user instigating such an alteration is checkedagainst a user list in the map to determine whether or not thealteration is allowed. If the alteration is not allowed, the request isignored, but preferably the users may then save the data themselves totheir own database or data maps as a private file or even copy the fileto a share for which they have access rights. These shares willpreferably also exhibit the revision control mechanism as describedabove.

Preferably, joining the share will mean that the users subscribe to ashared amount of data storage space and reduce one or more othersubscriptions, namely a 10 Gbyte share is created, and then theindividual gives up 10 Gbyte, or equivalent dependent on systemrequirements which may be a multiple or divisor of 10 Gbyte) Anotheruser joining result in them both having a 5 Gbyte space to give up and 5users would mean they all have a 2 Gbyte or equivalent space to give up.So with more people sharing, requirements on all users reduce.

Next, shared access to private files will be described with reference toFIG. 1 and FIG. 18, and also with reference to the aforementionedelement PT5.

TABLE 15 Steps of a method of shared access to private files in thecommunication system. Step Detail 1. User 1 logs onto a network 2. Theuser 1 Authenticates ID, namely gets access to his/her public andprivate keys to sign messages. This should NOT be stored locally butshould have been retrieved from a secure location- anonymously andsecurely. 3. User 1 saves a file as normal (encrypted, obfuscated,chunked, and stored) on the net via a signed and anonymous ID. This IDis a special communication Share ID (MSID) and is basically a new keypair created purely for interacting with the share users, namely to maskthe user's MID (i.e. cannot be tied to MPID via a share). So again theMSID is a key pair and the ID is the hash of the public key-this publickey which is stored in a data chunk called the hash and signed and puton the net for others to retrieve and confirm that the public keybelongs to the hash. 4. User 1 creates a share, which is a data map withsome extra elements to cover users and privileges. 5. File data added tofile map is created in the backup process, with one difference, namelythis is a map of maps and may contain many files, see 14 6. User 2 logsin 7. User 2 has authentication details (i.e. their private MPID key)and can sign/decrypt with this MPID public key. 8. User 1 sends a sharejoin request to user 2 (shares are invisible on the net, namely nobodyexcept the sharers to know they are there). 9. User 1 signs the sharerequest to state he/she will join the share. He/she creates his MSID keypair at this time. The signed response includes User 2's MSID publickey. 10. Share map is encrypted or sent encrypted (possibly by securemessenger) to User 1 along with the MSID public keys of any users of theshare that exist. Note the transmission of MSID public key may not berequired as the MSID chunks are saved on the net as described in 3, soany user can check the public key at any time; this just saves thesearch operation on that chunk to speed the process up slightly. 11.Each user has details added to the share these include public name(MPID) and rights (read/write/delete/admin etc.) 12. A description ofthe share file is provided; it will be appreciated that as each usersaves new chunks, he/she does so with the MSID keys; this means that ifa share is deleted or removed, the data chunks still exist in the user'shome database and he/she can have an option to keep the data maps andfiles as individual files or simply forget them all.

It will be appreciated that, as a user opens a file, a lock istransmitted to all other shares and they will only be allowed to open afile read only; they can request unlock, namely another user unlocks thefile, namely meaning it becomes read only. Non-logged in users will havea message buffered for them; if the file is closed, the buffered messageis deleted, as there is no point in sending it to the user now, andlogged in users are updated also. This will take place using themessenger component of the system to receive automatically messages fromshare users about shares, but being limited to that.

Next, there will be described a method of providing a public ID for thecommunication system, with reference to FIG. 1, and the aforementionedelement P17 thereof.

According to a related aspect of the present disclosure, a public andprivate key pair is created for a network of the communication system,where, preferably, the user is anonymously logged on, and preferably hasa changeable pseudo-random private id, which is only used fortransmission and retrieval of ID blocks giving access to that network.

Preferably, this public private key pair is associated with a public ID.This ID is transmittable in a relatively harmless way using almost anymethod including in an open communication, for email, ftp, www, etc.,but preferably in an encrypted form. Preferably, this ID is simpleenough to remember, such as a phone-number-type length. Preferably, thisID will be long enough, however, to be distinguishable in view of a sizeof contemporary world's population and more, for example this ID isbeneficially approximately 11 characters long, or more.

This public ID can be printed on business cards or stationary, like aphone number or email address, and beneficially cannot be linked to theuser's private ID by external sources. However, the user's own privateinformation makes this link by storing such data in an ID bit that theuser retrieves when logging into the communication system network, orvia another correspondingly valid method of secure networkauthentication.

This public ID is beneficially used in data or resource sharing withothers in a more open manner than is feasible with the private id.Moreover, use of the public ID keeps the private ID private, and allowsfor much improved inter-node or inter-person communications.

Next, there will be described secure communications in the communicationsystem, with reference to FIG. 1, and with reference to theaforementioned element P18.

According to a related aspect of the present disclosure, communicationsbetween nodes of the communication system should be both private andvalidated. Such validation is preferably implemented in an irrefutablemanner, but there is beneficially provided a plurality of options in thecommunication system for refutable communications, if required. Forirrefutable communications, a given user logs onto the network of thecommunication system, and retrieves his/her key pair and ID. This isthen used to start communications via the communication system.Preferably, the user's system will seek another node to transmit to, andreceive from, in a random manner; such randomness adds to the masking ofthe user's private ID as the private ID is not used in any handshakewith network resources apart from logging into the network.

As part of the initial handshake between a plurality of users of thecommunication system, a key is optionally passed. Preferably, this is acode passed between users over another communications mechanism in aform such as a pin number known only to the users involved, or it may beas simple as appending the user's name and other information to acommunication request packet, such as exists in some contemporaryinstant messaging clients, for example “ . . . David wants tocommunicate with you allow/deny/block”.

Unlike many communications systems today, the aforementioned handshakeis beneficially carried out on a distributed server-less network, forexample a peer-to-peer network formed by users' own computing devices,without any central serves associated with contemporary types of datacommunication networks. This however gives rise to a problem of what todo when users are off-line, and data memory associated with the users isthen not available to users of the communication system. In contemporarydata communication systems, messages are either stopped or stored on aserver, and in many cases not encrypted or secured. Incontradistinction, embodiments of the present disclosure allow users tohave messages securely buffered whilst off-line. Such secure bufferingis preferably achieved by the user's node creating a unique identifierfor only a present session and passing that ID to all known nodes in theuser's miadsafe.net address book. Users on-line get this present-sessionID immediately, whereas users off-line have this present-session IDbuffered to their last known random ID. Such a manner of operationensures that the ability of third parties to snoop on a user's messagesis significantly reduced, as there is no identifier such third partiesoutside the address book to provide any information indicative to wherethe name of the random ID bit associated with the messages are stored.The random ID bit is preferably used as a first part of an identifiedbuffer file name; when more messages are stored, another file is savedwith the random ID and a number appended to it representing a nextsequential available number. Therefore, a user will log on and retrievehis/her message sequentially. This allows buffered secured anddistributed messaging to exist within the communication system.

Next, there will described a method of signing documents, namely“document signing”, within the communication system, with reference toFIG. 1, and the aforementioned element P19 thereof.

According to a related aspect of the present disclosure, there isprovided a method of signing documents, wherein the method is aby-product of securing communications between nodes using asymmetricencryption as aforementioned, namely achieved by introducing anon-refutable link. Such a link allows not only for messagescommunicated between nodes to be non-refutable, but also for documentssigned in the same manner as messages to be non-refutable. Incontemporary data communication systems, somebody can easily steal auser's password or purposely attack users, as they are not anonymous;embodiments of the present disclosure provide an enhanced degree ofanonymity, and backs this up with access to resources; for example, thecommunication system enables documents to be signed and passed as beinglegally-enforceable between parties, for example as in a manner of acontract in one or more countries.

Next, a method of implementing contract conversations within thecommunication system will be described with reference to FIG. 1, namelyin respect of the aforementioned element P20 thereof.

According to a related aspect of the present disclosure, a conversationor topic can be requested under various contractual conditions, forexample within the communication system. The system may have implementedtherein a non-disclosure agreement as an example, and both parties tothe agreement digitally sign it automatically on acceptance of anassociated contract conversation, for example, in this case, anassociated non-disclosure conversation. Such an approach preferablyspeeds up and protects commercial entities entering into associatedagreements, or in situations where a mutual relationship is merely beinginvestigated. Preferably, other conditions can be applied here, such aspreferably full disclosure conversations, purchase order conversations,contract signing conversations, and so forth. Such interaction is allcarried out via the communication system, preferably having ready-madeenforceable contracts for automatic signing. These contracts maypreferably be country- or legal-domain-specific, and are optionally arerequire to be enforceable under laws of countries where suchconversations are happening. This requires the users, preferablyautomatically, to use a combination of geographic IP status and byselecting which is their home country and where they are at that timelocated and having that conversation. Preferably, only the discussionthread is under this contract, allowing any party to halt the contractbut not the contents of the thread, which is under contract. Preferably,in operation of the communication system, there is employed a very clearintent statement for a given conversation, to which both parties agree.This statement beneficially forms a basis of a contract in a event ofany debate subsequently arising in respect of the contract.

Next, a method of ms_messenger will be described, with reference to FIG.1 and Table 16, and the aforementioned element PT6 thereof.

TABLE 16 Steps of a method of ms messaging using the communicationsystem Step Detail 1. A non-public ID, namely preferably one which isused in some other autonomous system, is used as a sign-in mechanism andcreates a Public ID key pair. 2. The user selects or creates his/herpublic ID by entering a name that can easily be remembered (such as anickname) the network is checked for a data element existing with a hashof this and, if not there, this name is allowed. Otherwise, the user isasked to choose again at step 1 of Table 16. 3. This ID is called theMPID (communication public ID) can be passed freely between friends orprinted on business cards, and so forth as an e-mail address, namely ina contemporary manner. 4. To initiate communications, a user (initiator)enters the nickname of a person (receiver) with whom he/she is trying tocommunicate, with perhaps a short statement (like a prearranged pin orother challenge). The receiver agrees or otherwise to this request,wherein disagreeing means a negative score starts to build with theinitiator. This score may last for hours, days or even months dependingon a regularity of refusals. A high score will accompany anycommunication request messages. Users may set a limit on how manyrefusals a user has prior to being automatically ignored. 5. Allmessages now transmitted are implemented in an encrypted manner, withthe receiving party's public key, making messages less refutable. 6.These messages are optionally communicated via a proxy system, oradditional nodes to mask a location of each user (for example initiatorand/or receiver). 7. This system also allows document signing (namelyuse of digital signatures) and contractual conversations. In contractualconversations, a contract is signed and shared between associated users.Preferably, this signed contract is equally available to all in a signed(non-changeable manner) and retrievable by all associated contractualparties. Therefore, the method is well suited to being implemented in adistributed environment, for example as pertains to the communicationsystem. These contracts are, for example, NDA's, Tenders, PurchaseOrders and so forth. 8. This may in some cases require parties to provetheir identity, wherein such proof of identity can take many forms, forexample from dealing with drivers licenses to utility bills being signedoff in person, or by other electronic methods such as inputting passportnumbers, driving license numbers, and so forth. 9. If the recipient ison-line, then messages are sent straight to them for decoding. 10. Ifthe recipient is not on line, messages are require to be buffered asrequired for contemporary e-mails. 11. Unlike contemporary e-mailsthough, the method is implemented via the communication system which isa distributed system with no servers in which to buffer. In thecommunication system, messages are stored on the net and are encryptedwith the receiver's public key. Buffer nodes may be known trusted nodesor not. 12. Messages will look like “receiver's id. message 1. message2” or simply be appended to the user's MPID chunk; in both cases,messages are signed by the sender (initiator). This allows messages tobe buffered in cases where the user is offline.

When implementing the method, when the user comes on-line, he/she checkhis/her ID chunk and looks for appended messages as above, for exampleID.message1 and so forth, which is for example in a format“MPID.<message 1 data>.<message 2 data>”, and so forth.

The communication system is operable to support sending of automaticsystem messages, for example in a case of sharing shared data, whereindata maps can exist on everyone's database and never be transmitted orstored in an open state, thereby avoiding eavesdropping from occurring.File locks and changes to the maps can automatically be routed betweenusers using the messenger system as described above. Such automaticrouting is straightforward to achieve on account of the distributednature of communication system, in contradistinction to othercontemporary known messaging systems. In the maidesafe.net system, thesesystem commands are strictly limited for security reasons and areinitially used to send alerts from trusted nodes and updates to shareinformation by other shares of a private file share, for example whetherthey are speaking with them or not. In the communication system, anavoidance of a need of e-mail servers also prevents occurrence of e-mailspam, which is a problem associated with operation of conventionalcontemporary e-mail systems.

Next, a method of performing anonymous transactions within thecommunication system will be described with reference to FIG. 1, namelywith regard to the aforementioned element P24.

According to a related aspect of the present disclosure, thecommunication system is capable of providing a platform to performingtransactions in a global digital medium is made available in conjunctionwith the system. Such transaction is achieved by passing signed creditsto sellers in return for goods, thereby providing a mechanism forexchange of consideration. The credits are beneficially implemented asdata chunks with a given worth preferably 1, 5, 10, 20, 50, 100, and soforth units, for example conveniently referred to as being “cybers” inthis case; however, the madisafe.net system also provides a perfectplatform for using other types of representations of consideration, forexample BitCoin and so forth. These cybers are a digital representationof a monetary value and can be purchased as described below or earned,for example, for giving up machine resources such as disk space or CPUtime, and so forth. Beneficially, many different ways of earning cybersare beneficially provided in the communication system. Such a system forhandling consideration for making purchases via use of the communicationsystem is potentially more secure than contemporary banking systems,where institutions such as the Federal Reserve in the USA create fiatcurrency from nothing, in a World where perpetual growth is expected byfinancial markets, but not possible in reality due to finite Earthresources. The communication system provides a far superior solution incomparison to contemporary banking systems and financial structures.

A cyber is, in practice, a digitally signed piece of data containing acorresponding value statement, for example “10 cybers” and preferably aunique corresponding serial number. During a transaction, a givenseller's serial number database is checked for validity of the cyberalone. The record of the ID used to transact is preferably nottransmitted or recorded. This cyber will have been signed by the issuingauthority as having a value. This value will have been proven, andpreferably initially will actually equate to a single currency forinstance linked to a Euro, or to a real non-fiat item of worth such as adefined amount of a precious metal, for example Gold or Silver, storedin a precious metals repository institution. This value will preferablyalter through time as the communication system hosting the cybercurrency increases in capability.

Some sellers may request non-anonymous transactions, and if a given useragrees, he/she will then use a public ID creation process toauthenticate a non-anonymous transaction and may have to supply moredata. However, there may be other sellers who will sell anonymously.Such a manner of financial transaction potentially has a dramatic effecton marketing and demographic analysis, and so forth, as some goods willsell anywhere and some will not. It is assumed that this communicationsystem hosting the cyber, or similar type of verifiable currency, allowsprivacy and freedom to purchase goods without being analysed. Again,this avoids unauthorized eavesdropping and spying of governmentalorganisations, for example the NSA (USA) and GCHQ (United Kingdom).

The aforementioned process of transacting the cybers will preferablyinvolve a signing system, such that two persons in a given transactionwill actually pass the cyber from the buying person (“buyer”) to theselling person (“seller”). Such a process will preferably alter thesignature on the cyber to the seller's signature. This new signature isreported back to the issuing authority, responsible for issuing cybers.

Next, there will be described a method of interfacing, in respect of thecommunication system, with non-anonymous systems, with reference to FIG.1, and with regard the aforementioned element P23.

According to a related aspect of the present disclosure, a situationpotentially arises wherein people purchase digital cash or credits fromany seller of the digital cash or credits. A given seller preferablycreates actual cash data chunks which are signed and serialised toprevent forgery. This is preferably accountable as with contemporaryactual cash, namely to prevent fraud and counterfeiting. In anembodiment of the present disclosure, sellers are preferably registeredcentrally in some cases. Users can then purchase cybers for contemporarycash, and store these cybers in their database of files in a system,preferably such as the aforementioned communication system.

As a cyber is purchased by a purchaser, it is preferably unusable and infact simply a reference number which is utilized to claim the cyber'smonetary value by the purchaser's system. This reference number ispreferably valid for a period of time. The purchaser then logs intotheir system, for example the communication system, and inputs thereference number via a secure communications medium as a cyber request.This request is analysed by a cyber issuing authority and acorresponding transaction process begins, defined by the referencenumber. Preferably, the cyber is signed by the issuing authority thatthen preferably encrypts it with the purchaser's public key and issues asigning request. The cyber is not valid at this point. Only when asigned copy of the cyber is received by the issuing authority is theserial number made valid and the cyber is live for the purchaser toemploy, for example for claiming resources, namely physical productsand/or services.

This cyber now belongs to the purchaser and validated by the issuer. Tocarry out a transaction, such a process is preferably carried out again,namely the seller asks for payment and a cyber signed by the buyer ispresented; this cyber signed by the buyer is validated by checking withthe issuer that the cyber's serial code is valid and that the buyer isthe actual owner of the cyber. Preferably, the buyer issues adigitally-signed transaction record to the issuing authority to statehe/she is about to alter that cyber's owner. This transaction record isthen passed to the seller, who is then requested to sign it. The sellerthen signs the transaction record pertaining to the cyber and requeststhe issuing authority to accept him/her as new owner via a signedrequest. The authority then simply updates the current owner of thecyber in their records.

These transactions, for example with reference to cybers, are preferablyanonymous, as users should be beneficially using a private ID toaccomplish this process. This private ID can be altered at any time, butthe old ID should be saved to allow cyber transactions to take placewith the old ID.

Next, anonymity within the communication system will be described, withreference to FIG. 1, and regarding the aforementioned element P25.

According to a related aspect of the present disclosure, there isprovided a system of voting which is non-refutable and also anonymous.Such non-refutable and anonymous features are a requirement to allowfree speech and thinking to take place on a global scale withoutrecrimination and negative feedback as encountered in contemporarysituations.

To partake in a vote, the user will have to be authenticated as aboveand then preferably be presented with an issue on which a vote is to betaken. The user then uses a private ID key to sign their voteanonymously. Optionally, non-anonymous irrefutable voting may also takeplace in the system by simply switching from a private ID to a publicone. This preferably forms the basis of a petition based system as anadd-on to the voting system.

The system requires that a block of data can be published, namelypreferably broadcast to each user via a messenger function, and pickedup by each user of the system and presented as a poll. This poll is thensigned by the user, and sent back to a poll issuer whose system willcount the votes and preferably show a constant indication of the votesso far accumulated, for example in substantially real-time.

As there are public and private IDs available, then each vote preferablyrequires only one ID, namely a unique ID, to be used to prevent doublevoting. Preferably, geographic IP may be used to establish geographicanalysis of the voting community particularly on local issues.

Next, a voting system pursuant to the present disclosure will bedescribed with reference to FIG. 1, namely in relation to theaforementioned element PT8, and also with reference to FIG. 20. Detailsof a method of operating the voting system are provided in Table 17.

TABLE 17 A method of operating a voting system based upon thecommunication system Step Detail 1. A vote is created in a normalfashion; it could be a list of candidates or a list of choices thatusers have to select. Preferably, this list will always have an “I donot have enough information” option appended to the bottom of the list,namely to ensure that voters have sufficient knowledge to make aninformed decision. A limit on the last option should be stipulated as alimit to void the vote and redo the vote with more information. 2. Thisvote is stored on the system with the ID of the voting authority. Thismay be a chunk of data called with a specific name and digitally signedfor authenticity. All storage nodes may be allowed to ensure certainauthorities are allowed to store votes, and only store votes digitallysigned with the correct ID. 3. A system broadcast may be used to leteveryone interested know that there is a new vote to be retrieved. Thisis an optional step to reduce network congestion with constant checkingfor votes; other similar systems may be used for the same ends. 4. Anon-anonymous user logged into the net will pick up the vote. This is auser with a public ID known at least to the authority. The vote may infact be a shared chunk that only certain IDs have access to or know ofits location (i.e. split onto several component parts and a messagingsystem used to alert when votes are ready). 5. An anonymous user may belogged onto the net and may in fact use a random ID to pick up the vote.6. The vote is retrieved. 7. The system will send back a signed (withthe ID used to pick up the vote) “I accept the vote”. 8. The votingauthority will transmit a ballot paper, namely a digitally-signed (andperhaps encrypted/chunked) ballot paper. This may be a digitally signed“authorisation to vote” slip which may, or may not, be sequentiallynumbered or perhaps a batch of x number of the same serial numbers (toprevent fraud by multiple voting from one source, namely to issue 5 samenumbers randomly and only accept 5 votes with that number). 9. Usermachine decrypts this ballot paper. 10. The users system creates a onetime ID + key pair to vote. This public key can be hashed and stored onthe net as with a MAID or PMID so as to allow checking of any signed orencrypted votes sent back. 11. The vote is sent back to the authoritysigned and preferably encrypted with the authority's public key. 12. Inthe case of anonymous or non-anonymous voting, this may be furthermasqueraded by passing the vote through proxy machines en route. 13. Thevote is received and a receipt chunk put on the net. This is a chunkcalled with the user's temp (or voting) ID hash with the last bitshifted or otherwise knowingly mangled, so as not to collide (namely besimilar to) with the voting ID bit the user stores for authentication oftheir public key. 14. The authority can then publish a list of who votedfor what (namely a list of votes and the voting ID's). 15. The user'ssystem checks the list for the ID that was used being present in thelist and validates that the vote was cast properly. If this is not thecase: 16. The users system issues an alert. This alert may take manyforms and may include signing a vote alert packet; this can be a packedsimilarly (as in step 13), and altered to be a known form of the votechunk itself. There are many forms of raising alerts including, forexample, simply transmitting an electronic message through a messengerfunction or similar and possibly to a vote authentication party and notnecessarily the voting authority themselves. 17. The user has all theinformation to show the party investigating voting authenticity,accuracy, legality or some other aspect, thereby allowing faults anddeliberately introduced issues to be tracked down. 18. The user has theoption to remove all traces of the vote from his system at this time.

Next, features of a proven individual of the communication system willbe described, with reference to FIG. 1, and the aforementioned elementP26 thereof.

According to a related aspect of the present disclosure, there ispreferably using a system of anonymous authentication, preferably as inthe communication system.

Access by a given user to a system can be made possible by use ofinformation that the given user possesses, for example passwords andsimilar, or something that the given user physically has, for exampleiris/fingerprint or other biometric test. In order to prove anindividual's identity, the system preferably uses a biometric test. Suchtests are a key to a voting system, as such biometric tests become morebroadly adopted in contemporary society. It is inherent in this systemthat is herewith described, that any personally identifying data must bekept secret, and also that any passwords or access control informationis never transmitted.

When a user authenticates, the system can recognise whether or not theyhave done so biometrically. In this case, an account is regarded as aunique individual rather than an individual account. This is possible ascommunication can authenticate without accessing servers or databaserecords of a biometric nature, for example.

As a user logs into the communication system through a biometricmechanism, as aforementioned, a state of login is known so no login boxis required to be presented for the user to type in information in orderto access the system. This allows the system to guarantee that the userhas logged in biometrically. Moreover, the system on each machine isalways validated by communication on login to ensure this process cannotbe compromised. Preferably, some votes will exist in the communicationsystem only for biometrically-authenticated users.

Next, a method of distributed controlled voting for the meaidsafe.netsystem will be described, with reference to FIG. 1, and in regard of theaforementioned element P29 thereof.

According to a related aspect of the present disclosure, in order tomanage further the system, there has to be a level of control as well asdistribution to enable all users to access it at any time. Thedistribution of the votes is controlled as system messages are storedfor users, for example using the messenger system described earlier.

A main issue arising in practice with regard to a system such as thiswould be “what” is voted on and “who” poses the votes and words polls.This is key to the fairness and clarity of the system and process. Thisvoting system preferably always has a “not enough information” selectionto provide a route by which users are able to access information, sothat they are well informed before making any decision.

The system requires a group of individuals, who are preferably votedinto office by the public as the policyholders/trustees of the votingsystem. This group is beneficially known by their public ID and usetheir public ID to authenticate and publish a poll. This group ispreferably voted into office for a term and may be removed at any timevia a consensus of the voting public. For this reason, there isbeneficially continual polls on line which reflect how well associatedpolicyholders are doing as a group, and preferably in respect ofindividual members of the group as well.

According to a related aspect of the present disclosure, users of thesystem beneficially input to the larger issues on the system.Macro-management is beneficially carried out via the policyholders ofthe system, whom, as mentioned previously, may be voted in or out at anytime; however, larger issues are beneficially left to the users. Theseissues can preferably be one of more of:

-   (i) what licenses are used;-   (ii) costs of systems;-   (iii) dissemination of charitable contributions;-   (iv) provision to humanitarian and scientific projects of virtual    computing resources on large scales,    and so forth.

To achieve this, preferably a system message is sent out, where it isnot presented as a message but as a vote. This should show up in theusers' voting section of the system. User private IDs are them requiredto act on this vote, and the users are able to make their decision.

In the system, there will be appeals on these votes when it would beapparent that a conclusion of the vote is dangerous to either a smallcommunity or the system as a whole. Users beneficially have an option ofcontinuing with the vote and associated potential damage, butessentially the user decides and that is final. Preferably, this systemdoes not have a block vote or any other system which rates oneindividual over another at any time or provides an advantage in anyother way. This requires no ability to allow veto on any decision orcasting of votes by proxy, so that the authenticated user's decision isregarded as being properly recorded and final.

According to a related aspect of the present disclosure, there isprovided a system of perpetual data, self encrypting files and datamapping which allows a global anonymous backup and restore system fordata to exist, for example in a manner of a “drop box” for data files.This system is beneficially constructed from the aforementionedcommunication system, where data is susceptible to being made perpetualon a network, and anonymously shared to prevent duplication. This,together with the ability to check, manipulate and maintain revisioncontrol over files, adds a capability of a ‘time machine’ typeenvironment where data may be time stamped on backup.

This allows a system to rebuild a given user's data set as it was at anytime in history, since communication or similar technologies areemployed. Such rebuilding of the user's data may form a defence at timeswhere, in cases like prior art enquiries, insider dealing and similarare being considered, as the system is secure and validated by manyother nodes, and so forth. It is therefore feasible to show whatknowledge, at least from the point of view of owning the data pertainingto a subject, anyone had of certain circumstances.

According to a related aspect of the present disclosure, preferablyusing features of one or more aspects of the disclosure previouslydefined, taking distributed authentication, backup and restore alongwith data map sharing, the system can add to this an ability forgranular access controls. In this case, a node entering the network willrequest an authenticator to authorise its access. In this case theauthenticator will be a manager or equivalent in an organisation,whether matrix managed or traditional pyramid. This authorisation willtie the public ID of the authoriser to the system as having access tothis node's data and any other authorisations they make, for example inan authorisation chain. This allows an environment of distributed securebackup, restore and sharing in a corporate or otherwise privateenvironment.

According to a related aspect of the present disclosure, all of thecapabilities described here with the exception of the above will ensurethat a network of nodes can be created, in which users have securityprivacy and freedom to operate.

These nodes will have refutable IDs, for example MAID, PMID and similar,as well as non-refutable IDs, for example MPID, for different purposes;just as in human life in general, there are occasions when it isadvantageous to be identified, and other occasions when it is desirablenot to be identified.

According to a related aspect of the present disclosure, adding afunctionality of non-refutable messaging allows users not only tocommunicate genuinely and securely, but also a functionality tocommunicate under contracted terms. This allows for the implementationof legally-kept trade secrets, as implied with NDA agreements andsimilar, together with many more contracted communications. Thisbeneficially lessens a burden in system relating to legal issues such aslitigation, and so forth.

According to a related aspect of the present disclosure, adding afunctionality to create two voting systems, namely anonymous andnon-anonymous, allows the system to provide a mechanism for instantdemocracy. This is achieved by allowing a voting panel to be provided ina given user's account that is constantly updated with issues regardingthe system and initially improvements thereto. These votes arebeneficially anonymous.

In another anonymous voting scenario, for example based upon theaforementioned communication system, users are optionally capable ofcontinually voting on certain subjects, for example in a manner of arunning poll, wherein these subjects are optionally leaders ofmanagement boards, and so forth.

In a non-anonymous voting scenario, for example based upon theaforementioned communication system, a situation potentially ariseswhere there are one or more groups of identified people, for exampleidentifiable via their MPID, who have a common grouping such as acharity or similar, and they may require certain people to vote oncertain matters and be recognised. This is where the MPID isbeneficially used for voting purposes.

According to a related aspect of this present disclosure, there isadditionally provided a functionality, namely an ability to collect andtrade credits anonymously, thereby allowing users to sell machineresources they are not using, and also to trade on a network with a cashequivalent, for example in a manner of a fiat currency, and go abouttheir business on a network as they do in real life.

According to a related aspect of this present disclosure, there isprovided a system of self-encryption of data that does not require userintervention or passwords. The resultant data item then has to be savedor stored somewhere as in all methods. The self-encryption systemcreates cipher-text (encrypted) objects that are extremely strong andcloser to perfect in terms of reversibility, and producedifficult-to-guess uncompress-able output. The difficult-to-guess anduncompressable output equates to random results based on random inputdata and random, unrelated algorithm inputs plain text, key andinitialisation vectors in the case of modern symmetric ciphers. Theself-encryption system includes a file chunking module, file encryptionmodule, and a file obfuscation module.

The file chunking module splits an input data into several data chunks(C_(n)) based on the size of data file (f .size( )) and total number ofdata chunks. The total number of data chunks may depend on maximumnumber of data chunks, or maximum chunk size specified by the user. Inan example, the input data may be divided into chunks of size 256 kB.The file chunking module beneficially further takes a hash of each datachunk, and hashes the hashed data chunks to create a structure, referredto as a data map. The file content, namely input data is referred to asf_(c), file metadata is referred to as f_(m), and

file hash f _(h) ≡H(f _(c))orfh ≡H(H(C ₁)+H(C ₂)+ . . . H(C_(n−1)))  (1)

The data chunks are created with fixed size to ensure the set requiredto recreate the file is almost as large as the number of available datachunks in any data store. This data map is mapped to file metadatathrough f_(h).

In cryptographically secure hashing, the input data is analysed and afixed length key called the hash of the data is produced. Acryptographically secure hash is a one way function which creates outputthat has a uniform distribution and can be computed in polynomial time.The output should be in fact random, although can be affected by a sizeof input. The size of input required is dependent on the strength of thehash functions employed. A hash function can be thought of as a digitalfingerprint. Just as a fingerprint of a person is supposed to be unique,then a digital hash function is also supposedly unique. Two data pieceswith the same hash result leads to a collision, The more secure the hashalgorithm, then the likelihood of a collision is reduced. Again, similarto human fingerprinting, a hash cannot reveal data, just as afingerprint cannot reveal a person (i.e. the person cannot be recreatedfrom the print and the data cannot be recreated from hash)

The file encryption module uses two separate non-deterministic pieces ofdata, i.e, the encryption key (or password) and an initialisation vector(IV) for encryption of a data chunk. To ensure all data chunks of a fileencrypt to the same end result, the IV is determined fromnon-deterministic data, i.e. hash of one of the data chunks. Theencryption of data with encryption key and IV can be represented byEnc_([key][IV]) (data), where the key and the IV for encryption ofn^(th) chunk are derived from separate portions of the hash of n−1^(th)chunk. In an example, when the encryption algorithm is AES, the first 32bytes of the hash of n−1^(th) chunk are beneficially presumed to be thekey and the next 16 bytes are beneficially presumed to be the IV, and anencrypted data chunk C_(xen) is then formed from a data chunk C_(xn)using hash of a n−1^(th) data chunk C_(n−1), such that

C _(xen)≡Enc_([H(C) _(n−1[first 32 bytes]) _()][H(C) _(n−1[32-48 bytes])_()])(C _(xn))  (2)

The hash of the encrypted data chunk C_(xen) is conveniently representedas H_(C) _(xen) and the encrypted chunk C_(xen) is then beneficiallyrenamed with the corresponding hash H_(C) _(xen) .

The file obfuscation module pollutes a data chunk with data from otherdata chunks. In an example, for obfuscating an n^(th) data chunk C_(n),firstly an identically-sized data chunk is created by repeatedlyrehashing the hash of n+2^(th) chunk C_(n+2) and appending the result,i.e. H(C_(n+2))+H(H(C_(n+2)))+H(H(H(C_(n+2))))+ . . . . Thisidentically-sized data chunk may be referred to as XOR n^(th) chunk(C_(XORn)). Then, the XOR n^(th) chunk (C_(XORn)) is XORed (⊕) withn^(th) data chunk C_(n) to determine an obfuscated n^(th) chunk C_(xn).

In an example, a first obfuscated data chunk C_(x1)∂C_(XOR1)⊕C₁, asecond obfuscated data chunk C_(x2)∂C_(XOR2)⊕C₂, and so forth. Although,XOR has been selected to represent a logical operation to obfuscate thedata, this is not restrictive in any way and may be replaced by otherobfuscation methods.

TABLE 18 A method of self-encrypting data using the file chunking, fileencryption, and file obfuscation modules Step Detail 1. Split an inputdata into several chunks (C_(n)). 2. Take hash of each chunk (H_(c) _(n)). 3. In case of AES or similar cypher, use [keysize] (C_(n−1)) as thekey, use [next bytes](C_(n−1)) as the initialisation vector (IV); (forAES 0 to 32 bytes == key and 32 to 48 bytes == IV). 4. Createobfuscation chunk (OBFC_(n)) by concatenating the hashes of other chunks( [unused part of] C_(n−1) C_(n−2) and C_(n)). 5. Run encryption cypheror similar reversible method on (C_(n)), to produce (C_(random)) 6. Nowdata is considered to be randomised and of the same length as inputdata. 7. OBFC_(n) is also random output, but of a length less than theinput data. 8. Take OBFC_(n) (repeated) XOR C_(random) to produce outputdata. 9. Rename each with the hash of the new content and save thesehashes.

In the aforementioned method of encrypting data, the encryption of thedata chunks and then thereafter XOR'ing them together, namely forobfuscation purposes, provides synergistically extremely secure data,which is substantially impossible for NSA in the USA and GCHQ in the UKto decrypt, even using extremely powerful modern computers. When theobfuscation is performed before encryption, a much inferior result interms of data security is obtained. The encryption followed by XORobfuscation is very robust, as aforementioned.

The symmetric encryption algorithm (AES) introduces randomness to thedata, and the obfuscation module repeats random data. Therefore, theself-encryption process can be considered substantially, for practicalpurposes, as a form of one time pad.

Data Map: The data maps facilitate retrieval of plain-text from thecipher-text (encrypted) data chunks.

TABLE 19 Data map structure fh = H(H(c₁) + H(C₂) + . . . H(C_(n−1)))H(c₁) H(c_(xe1)) H(c₂) H(c_(xe2)) . . . . . . H(c_(n)) H(c_(xen))In the aforementioned data map structure, the file hash f_(h) in the toprow identifies the data and acts as the unique key for the input file.The left-hand-column includes all the passwords and IV's, which arederived from the original chunk hashes, and the right-hand-columninclude names of all the encrypted and obfuscated data chunks. The datamap structure facilitates retrieval of plain-text from the cipher-textchunks, where the retrieval process includes:

-   -   1) Retrieving the chunks listed in right hand column    -   2) Creating each XOR chunk again    -   3) Reversing the obfuscation stage    -   4) Decrypting each result    -   5) Concatenating the results.

Data Atlas or Recursive Data Maps:

The data maps (d_(m)) from multiple files can be concatenated into a newstructure, referred to as a data atlas (d_(a)), whered_(a)∂d_(m1)+d_(m2)+ . . . d_(mc). This data atlas is itself now a largepiece of data and may be fed into the self-encryption process, toproduce a single data map and more data chunks. The data chunks may bestored somewhere and the single remaining data map may be the key to alldata.

Modifications to embodiments of the invention described in the foregoingare possible without departing from the scope of the invention asdefined by the accompanying claims. Expressions such as “including”,“comprising”, “incorporating”, “consisting of”, “have”, “is” used todescribe and claim the present invention are intended to be construed ina non-exclusive manner, namely allowing for items, components orelements not explicitly described also to be present. Reference to thesingular is also to be construed to relate to the plural. Numeralsincluded within parentheses in the accompanying claims are intended toassist understanding of the claims and should not be construed in anyway to limit subject matter claimed by these claims.

What is claimed is:
 1. A method of protecting data in a peer-to-peernetwork of a plurality of nodes, comprising: splitting the data into aplurality of data chunks of one or more sizes, wherein the one or moresizes are randomly calculated based on the data; obfuscating theplurality of data chunks by swapping individual bytes of each data chunkwith individual bytes of every other data chunk until all bytes of eachdata chunk are swapped; encrypting the plurality of obfuscated datachunks; and storing the plurality of obfuscated and encrypted datachunks at the plurality of data storage nodes.
 2. The method as setforth in claim 1, wherein encrypting the plurality of obfuscated datachunks further comprises using a hash value of a given data chunk of theplurality of obfuscated data chunks as an input to an encryptionalgorithm to encrypt a next given data chunk of the plurality ofobfuscated data chunks.
 3. The method as claimed in claim 1, whereinencrypting the plurality of obfuscated data chunks further comprisesusing a symmetric encryption algorithm.
 4. The method as claimed inclaim 1, wherein encrypting the plurality of obfuscated data chunksfurther comprises: determining hash value of the plurality of obfuscatedand encrypted data chunks; applying the modulo division function to thedetermined hash value of the plurality of obfuscated data chunks togenerate a random number; and using the random number and the hash valueof the plurality of obfuscated data chunks to encrypt the data chunk. 5.The method as claimed in claim 1, wherein encrypting the plurality ofobfuscated data chunks further comprises: employing an encryption keyderived from known information from another of the plurality of datachunks.
 6. The method as claimed in claim 1, further comprising:maintaining multiple copies of the obfuscated and encrypted data chunksat the plurality of data storage nodes; regenerating, from uncorruptedcopies of the obfuscated and encrypted data chunks, one or morereplacement obfuscated and encrypted data chunks; and when anyobfuscated and encrypted data chunk becomes corrupted, replacing thecorrupted data chunk with a corresponding one of the replacementobfuscated and encrypted data chunks.
 7. The method as claimed in claim1, wherein the splitting, the obfuscating, the encrypting and thestoring are performed by a first user; the method further comprising:decrypting and de-obfuscating the obfuscated and encrypted data chunksby a second user cooperating with the first user over a secure data,video and/or audio communication link.
 8. The method as set forth inclaim 1, further comprising naming the plurality of obfuscated andencrypted data chunks using corresponding hash values of the datachunks.
 9. The method as set forth in claim 1, further comprisingrepeating the swapping a number of times equal to the number of theplurality of data chunks.
 10. The method as set forth in claim 1,further comprising, recording, in at least one data map stored inencrypted form at one or more of the plurality of data storage nodes,identities of data storage nodes at which the plurality of obfuscatedand encrypted data chunks are stored.
 11. A computer program product forprotecting data in a peer-to-peer network of a plurality of nodes, thecomputer program product residing on a non-transitory computer-readablestorage medium and comprising instructions which, when executed by aprocessor, cause one or more computers cooperating over a secure data,video and/or audio communication link to: split the data into aplurality of data chunks of one or more sizes, wherein the one or moresizes are randomly calculated based on the data; obfuscate the pluralityof data chunks by swapping individual bytes of each data chunk withindividual bytes of every other data chunk until all bytes of each datachunk are swapped; encrypt the plurality of obfuscated data chunks; andstore the plurality of obfuscated and encrypted data chunks at theplurality of data storage nodes.
 12. The computer program product as setforth in claim 11, wherein the plurality of obfuscated data chunks areencrypted using a hash value of a given data chunk of the plurality ofobfuscated data chunks as an input to an encryption algorithm to encrypta next given data chunk of the plurality of obfuscated data chunks. 13.The computer program product as claimed in claim 11, wherein theplurality of obfuscated data chunks are encrypted using a symmetricencryption algorithm.
 14. The computer program product as claimed inclaim 11, wherein the plurality of obfuscated data chunks are encryptedby: determining hash value of the plurality of obfuscated data chunks;applying the modulo division function to the determined hash value ofthe plurality of obfuscated data chunks to generate a random number; andusing the random number and the hash value of the plurality ofobfuscated data chunks to encrypt the data chunk.
 15. The computerprogram product as claimed in claim 11, wherein the plurality ofobfuscated data chunks are encrypted using an encryption key derivedfrom known information from another of the plurality of data chunks. 16.The computer program product as claimed in claim 11, wherein theinstructions, when executed on a processor, further cause one or morecomputers to: maintain multiple copies of the obfuscated and encrypteddata chunks at the plurality of data storage nodes; regenerate, fromuncorrupted copies of the obfuscated and encrypted data chunks, one ormore replacement obfuscated and encrypted data chunks; and when anyobfuscated and encrypted data chunk becomes corrupted, replace thecorrupted data chunk with a corresponding one of the replacementobfuscated and encrypted data chunks.
 17. The computer program productas claimed in claim 11, wherein the splitting, the obfuscating, theencrypting and the storing are performed by a first of the one or morecomputers and wherein, the instructions, when executed on a processor,further cause a second of the one or more computers to decrypt andde-obfuscate the obfuscated and encrypted data chunks.
 18. The computerprogram product as set forth in claim 11, wherein, the instructions,when executed on a processor, further cause the one or more computers toname the plurality of obfuscated and encrypted data chunks usingcorresponding hash values of the data chunks.
 19. The computer programproduct as set forth in claim 11, wherein, the instructions, whenexecuted on a processor, further cause the one or more computers torepeat the swapping a number of times equal to the number of theplurality of data chunks.
 20. The computer program product as set forthin claim 11, wherein, the instructions, when executed on a processor,further cause the one or more computers to record, in at least one datamap stored in encrypted form at one or more of the plurality of datastorage nodes, identities of data storage nodes at which the pluralityof obfuscated and encrypted data chunks are stored.